TK.

Once the MIOS screen pops up, the application starts to access the SID via the 74HC595 shift registers. If you would connect an amp to one of the 74HC595 pins, I'm sure that you would hear such digital noise. Are you sure, that there isn't a "hidden" connection between the 74HC595 and the transistor amp stage (compare with http://www.ucapps.de/mbhp/mbhp_sid_v3.pdf Schematic) Best Regards, Thorsten.

Hi Andrea, is this a switch which provides a common pin, which can be select between 6 terminals? Then you could connect it the same way like shown in this schematic: The resistors are connected between the terminals, and the common pin is connected to the analog input. Best Regards, Thorsten.

Hi Enrico, I don't see a risk here --- but which master keyboard are you using? It could be interesting to know for the case that somebody owns the same Best Regards, Thorsten.

Hallo Lars, hast Du den Tip mit dem evtl. fehlenden 1k Pull-Up an der SC Leitung weiterverfolgt? Wenn es ohne IIC Modul funktioniert, ist die Wahrscheinlichkeit sehr hoch, dass es daran liegt. Gruss, Thorsten.

Too bad that the video stops where the bass drum begins! :-( Congratulations for the good marks! :) Best Regards, Thorsten.

Second assumption: I guess that you are not using the audio input of the SID - is it connected to ground? (this is recommented) Best Regards, Thorsten.

Yes, it should behave like a common PIC18F452 Maybe an issue with your programmer? Which one did you use? And did you perform a verify after programming the bootloader to check the flash content? Maybe the code memory protection is activated, so that flash cannot be overwritten via software? Best Regards, Thorsten.

looks fine, does it boot? Best Regards, Thorsten.

It sounds like digital noise, couldn't this be a corrupted patch? You are writing that the testtone application works well - does it mean that you don't hear such noise in background anymore? Then I would say, that it is very likeley that you missed to solder the two 1k Pull-Ups for the SC/SD line of the BankStick? Best Regards, Thorsten.

Hi, some feedback from MBSEQ V3 users about the workflow would also be interesting for me. Best Regards, Thorsten.

This is only an issue for devices which get use of the ECAN peripheral, and for MIDIboxes which are using excotic displays which don't support the 4bit mode properly (currently I'm only aware of issues with PLED (they will be discontinuied anyhow) and VFD displays, common LCDs are working ok - I tested this with all LCDs I own, and I own a lot of different types! ;-) The drawback of the 8bit mode workaround: two IO pins get lost - so this is no general solution. To avoid misunderstandings I repeat this in other words: for MBSID V2 users this issue is not the end of the world, as for the case a LCD doesn't support the 4bit mode there is a workaround. But this workaround is only sufficient for MBSID V2 - it wouldn't work with a MIDIbox which allocates all IO pins. Therefore don't be afraid, the layouts don't need to be changed. :) Best Regards, Thorsten.

Thanks! I will come back to your offer once I've collected some more experiences about this hacking stuff. I own an old Linksys router which was damaged after a thunder storm. The ethernet connection is still working, only the DSL link is affected - after this "accident" I started to think about a new purpose for the device... propably I found it ;) Best Regards, Thorsten.

Mr. Selfservice (a nice matching avatar name btw. ;-)) Could you please add a link to the overworked layout to this wiki page, so that it doesn't get lost: http://www.midibox.org/dokuwiki/doku.php?id=layout_improvements Thanks for your help! :) Best Regards, Thorsten.

Welcome to the forum! :) Would it also be possible to provide a second WR# line instead of an additional address line? This would make your chip compatible to the MBSID V2 stereo SID design (see http://www.ucapps.de/midibox_sid_manual_l.html for sound examples) Best Regards, Thorsten.

I just want to inform you, that the first beta release of MBSID V2 can be expected soon. I'm planning to work out the last details next week. Also some documentation about the multi engine and the new hardware requirements needs to be written, but thereafter a full working firmware with support for Lead and Multiengine + Ensembles should be available. (to give you are more exact date: if nothing else happens - and currently each day something unexpected can happen - maybe next friday or earlier). I'm already curious about your feedback, as this is very important in this phase were I'm going to freeze certains parts of the engine (conceptional changes will be difficult in future). There is no SysEx editor available yet, and I would prefer if somebody else could implement it. Either JSynthLib based, a dedicated java application or something else which is platform independent. So, if somebody with programming skills is searching for a challenge (the synth engine is much more complex than the one of MBSID V1), hands up! :) This means, that people who want to test the new firmware need a control surface. As mentioned in the past, a Step A surface will be sufficient, but you need at least one SHIFT (the previous LINK) button to activate special functions. This also means, that you need to add a second shift register (-> DINX2). And by doing so, you could also add the Page Up/Down (the previous CC/EDIT) button for easier selection of synth elements (e.g. OSC, LFO, ENV, WT, ...) Step B and Step C owners will be able to use the new firmware without additional modifications. Just only the PIC needs to be replaced. And if you have the choice: the stereo option (two MBHP_SID modules controlled from a single core) should be prefered, as this is one of the most important features (I don't use external Fx gear anymore since this option is implemented :)) So, for people who already have a fully stuffed MBSID V1, just leave two slaves unbusy, and connect the SID modules to the master and first slave instead - you will love the fat sound! :) All these requirements will be written down and illustrated in the manual, so please be patient and don't ask here - I will document it with the same quality as known from MBSEQ V3, I just need some more time... Best Regards, Thorsten.

Great! It could be a wireless MIDI server and a cheap embedded OSC->MIDI->OSC translator Than more I'm thinking about it, than more I find such a project attractive. Too bad that MBSID V2 will keep me busy in the next months, but this is maybe a nice toy for long winter evenings Best Regards, Thorsten.

Hi Bob, maybe these buttons are fine for you? They are available at reichelt.de (type "taster" into the search mask), and there are different colours and version available (with or without integated LED). But they are not cheap: 1.85 EUR per piece There are also these round ones which I do prefer: they are available for 0.72 EUR per piece Also conrad.de has a wide variety of buttons. Best Regards, Thorsten.

I like the idea to vary the gatelength for controlling an envelope, but I can also say, that the current implementation is not sufficient for that what you are planning. The gatelength of a step is quantized into 24 microsteps, derived from the internal or external MIDI clock. In order to improve the readability, the MBSEQ doesn't display the number of steps, but the relative gatelength in percent (4%, 8%, 13%, 17%...100% and Glide). There is no 0% as 0% means no gate (trigger switched off) This quantisation is perfect for common patterns, as it scales with the BPM. But I think that you are searching for a way to enable the gate for a specific time. E.g., from 1 to 127 mS in steps of one mS, independent from the BPM, and maybe controlled with the velocity (advantage: when an event layer is setuped for Drum mode, you can control 3 drumlines with variable velocity from a single track) Best Regards, Thorsten.

What I mean: I just have removed the comment about the compatibility from my webpage, because it is obsolete. I wrote this 4 years ago, where most of my projects were running on a PIC16F877 with a totally different firmware. Ok, I see that I'm not the right person who could help you... Ignorant: it seems that this word has a different meaning in english. Thats funny. Not sure how many times I wrote it for a totally different purpose. ;-) Best Regards, Thorsten.

removed hint (prehistoric comment from 2003) No more time to answer all your questions - sorry, I'm an ignorant guru. Best Regards, Thorsten.

Dass auch ungueltige Werte im Pattern landen koennen, ist ein wichtiger Input. Somit muss irgendetwas im Flashspeicher korrupt sein, denn es gibt keine Routine, die bspw. den Event Mode auf 16 stellen wuerde. Zur weiteren Auswertung braeuchte ich mal einen kompletten Speicherabzug von Deinem PIC. Den koennte ich dann bei mir aufspielen, und naeher untersuchen. Am einfachsten laesst sich der Dump via MIDI-Ox erstellen: SysEx Fenster oeffnen, folgende Zeile in das Command Window pasten: F0 00 00 7E 40 00 01 00 00 20 00 F7 und mit Command Window->Send/Receive SysEx den Transfer starten. Im Display Window werden 37896 Bytes empfangen, diese mit Display Window->Save as.. in ein SysEx file abspeichern (bspw. flash_0.syx) Dann die zweite Haelfte requesten mit: F0 00 00 7E 40 00 11 00 00 20 00 F7 und in flash_1.syx abspeichern. Zusaetzlich vielleicht auch noch einen Dump vom internen EEPROM machen: F0 00 00 7E 40 00 01 20 00 01 00 F7 und in eeprom.syx abspeichern an tk@midibox.org schicken. Die MIDIbox wird nach einem Dump neu gebootet - keine Panik, das ist normal ;) Gruss, Thorsten.

Francois: maybe you remember, that we modified the AOUT module for your polykobol to a voltage range between -5V..+5V - you could use it for the PS3100 now, just upload the MIDIbox CV firmware to the core module, which is currently in the IBM box ;-) Sooner or later, we could modify the firmware, so that it can control the DOUT + AOUT module - only one core would be required anymore, and the second core is free for some other MIDIfication stuff ;) Best Regards, Thorsten.

Hallo Lars, Das war vielleicht der entscheidende Hinweis - koennte es sein, dass die Track-Gruppe von G1Tx auf G2Tx, G3Tx oder G4Tx (x=Track Nummer) wechselt? Dann wuerde es an der F4 Taste legen, mit der die Gruppe umgeschaltet wird. Diese Taste hatte in der alten Firmware noch keine besondere Funktion. Druecke mal mehrmals die F4 Taste - kommen dadurch die alten Einstellungen wieder zum Vorschein? Falls die F4 Taste nicht funktioniert (Wackelkontakt oder Kurzschluss?), kannst Du die Gruppe auch mit Encoder #1, oder mit gehaltener Mute-Taste + GP 1..16 Taste wechseln. Gruss, Thorsten.

I can only strongly suggest to spend some more effort into the planning phase, and especially to do some programming evaluations before building up the complete LED matrix in order to find out the best performance solution which meets your requirements (which are still a little bit unclear to me... however :)) Just for the records - this is how a 8x64 = 512 LED matrix could be controlled from the MIOS SDCC wrapper: // LED pattern array - prepared for 512 LEDs (=64 bytes) unsigned char led_patterns[64]; ///////////////////////////////////////////////////////////////////////////// // This function is called by MIOS before the shift register are loaded ///////////////////////////////////////////////////////////////////////////// void SR_Service_Prepare(void) __wparam { static unsigned char row_ctr; unsigned char i; // increment counter on each cycle, wrap at 8 row_ctr = (row_ctr + 1) & 0x07; // select LED row, the appr. DOUT is the 9th shift register in the chain MIOS_DOUT_SRSet(8, 1 << row_ctr); // init pattern of DOUT 1..8 (= 64 outputs) // offset depends on row_ctr for(i=0; i<8; ++i) MIOS_DOUT_SRSet(i, led_patterns[row_ctr * 8 + i]); } [/code] So, there is no need for a special timer, as the update cycle of the SR upload is already interrupt driven by a timer resource. Just to highlight it again (for the case that you change your decition): such a LED matrix, where one shift register controls the common line of so many LEDs (64 per row) definitely requires a transistor on the 9th DOUT (where the common lines are connected) Best Regards, Thorsten.

It's the toggle function which you need to activate. It can be done for each button seperately. You could do this from the menu interface (go into MIDI learn mode and press the SELECT button to change the button mode before a new MIDI message is learned), or if you want to use the mk_syx.zip script, write @Toggle instead of @OnOff I believe the button behaviour can also be changed with Serge's editor... so there should be multiple ways which are worth for trying out :) Best Regards, Thorsten.