TK.

Die Geschwindigkeitsmessung wird MIOS-Intern vorgenommen, ist assembleroptimiert, und funktioniert mit bis zu 64 encodern gleichzeitig (unabhaengig voneinander). Fuer jeden einzelnen Encoder zaehlt MIOS die Scanzyklen (*) zwischen den Flanken, skaliert den Zaehlerwert runter und uebergibt sie der Applikation als Inkrementer. (*) Encoderpins werden jede mS gescannt. Ich bin mir nicht sicher, ob dies nicht meiner Idee entspricht, die ich vor 8 Jahren hatte, und in die MIDIbox firmwares eingebaut habe (wer weiss, wer die bisher schon alles geklaut hat ;)) Bei ungerasterten Encodern kann man die Impulse meist verdoppeln oder gar vervierfachen, wenn man nur schnell genug scannt, und mit jeder erkannten Flanke inkrementiert. Der entspr. Encoder-type heisst "MIOS_ENC_MODE_NON_DETENTED", und die Vervierfachung der Aufloesung funktioniert auch mit billigen 0.25 Cent Encodern aus China ;-) Diese Waveforms sollen das Prinzip der Vervierfachung verdeutlichen: Gruss, Thorsten.

Hi Steve, yes, I'm interested in testing your firmware, especially under MacOS. SysEx corruption: some weeks ago ASSI informed me about a proper software workaround: using MIDItrix V1.24 to defractment the MIDI stream before it will be sent to the USB interface. He also contacted Microsoft, and got the answer, that they are aware of this issue, and fixed it in Vista. They are not planning to fix it for XP anymore, but they asked him for details, so that the issue can be properly documented in a KB note Which reminds me, that I have to deliver some input... ok, I will do this while testing your firmware ;) Best Regards, Thorsten.

Thank you for the nice words! :) A remote control feature isn't that expensive, and it wouldn't cost much effort so long you don't expect a detailed documentation... Btw.: for those who haven't experienced the full feature set of MBSID V2 yet, Rutger's upcoming editor will help a lot to get an oversight. Teaster: Best Regards, Thorsten.

In MBSEQ, triplets are generated by selecting a different predivider. The internal 96 ppqn are divided by 6 (-> 16 ppqn) and 4 (-> 24 ppqn) to avoid fractions or expensive math There are two reasons why I haven't done this for MBSID yet. One reason is, that SID_SE_STATE (which propagates the predivided clock events... and more flags) is fully allocated, another reason is, that SID_BASE section 0x100..0x1ff is completely allocated as well, so that I need to find some ways to free memory before introducing such special features. It's still in my focus to get the firmware bugfree before starting with optimisations, a proper solution for triplets will be provided by default in a pre 2.0 release. Of course, meanwhile you are free to tinker on your own solution, or to remove features you don't need (variables in SID_BASE section) to get some free memory... Best Regards, Thorsten.

Does your controller send "B0 xx 41" on clockwise encoder turns, and "B0 xx 3F" on anticlockwise turns? Then I could easily add a function which allows to "emulate" the encoders of the MBSID CS (as I wrote: remote control) The buttons should send MIDI controllers as well, e.g. "B0 xx 7F" if pressed, "B0 xx 00" if depressed. MBSID won't be able to control external LEDs (the slow MIDI protocol would block the firmware too much) Best Regards, Thorsten.

Hallo, A1 ist momentan nicht speicherbar - das sollte mit der Release am Wochenende wieder funktionieren. Hintergrund: A1 befindet sich nicht im BankStick, sondern im internen EEPROM. Nach der Optimierung der BankStick-Speicherroutine (Backgroundsaving) habe ich die EEPROM routinen noch nicht dementsprechend angepasst Absturz bei A6: der Fehler kommt mir bekannt vor, den gab es in 0.9, wurde aber in 0.9b gefixed. Verwendest Du wirklich die aktuelle Version? Falls ja: koenntest Du mir bitte ein Backup von Deinem Bankstick zuschicken? (-> Mehr Infos hier) Zum Abspeichern bspw. das SysEx tool von MIDI-Ox hernehmen. Bei einem 64k BankStick folgenden String senden: [tt]F0 00 00 7E 40 00 01 40 00 40 00 F7[/tt] und mir den empfangenen SysEx dump zuschicken "No BackStick" Problem: von welchem Hersteller kommt der Chip? ST, Atmel oder Microchip? Gruss, Thorsten.

Thanks for selling only here (inside the community), and not at ebay or other commercial platforms! permission granted, posting moved to flearmarked Best Regards, Thorsten.

Pierrot already soldered the veroboard for his MIDIbox64 in 2002, but got stucked because of a missing PIC burner. It took 5 years, until he continued with his work, and finally it's finished! :) Homepage: http://www.scrubsonrecords.de

This "red beast" has been created by Francois aka. Polykobol. On top of a Yamaha TX816 (8 modules, 128 voices, 48 operators) Which one produces better sounds? ;-)

There are a lot of improvements/bugfixes/new features between this early alpha version, and the current v3.2 release. Most of the new functions are documented in the ChangeLog It's definitely worth the time for doing the update. So far I see, you only need to adapt the button and LED assignments, this can be done in a single file (-> setup_mbseq_v3.asm The application has to be rebuilt with GPASM (MPASM not supported anymore). And Quickstart Guide can be found here Best Regards, Thorsten.

Yes, 5V is sufficient for the whole hardware, and an Audio In is not provided Best Regards, Thorsten.

Additional hints: between clearing all ADSR registers and setting new values, you should wait at least for 20 mS to ensure, that the envelope generator has reached the lowest level, before setting the gate again. If you re-configure the ADSR earlier, the next envelope could fail (related to ADSR bug -> "hick ups") Since you are at a very early programming phase, I propose you to use a static ADSR setting "00F0". Attack, Decay, Sustain are set to 0 - with this configuration, you won't notice effects related to the ADSR bug -> better for debugging Once the voices can be triggered properly, you should setup an interrupt driven timer which takes care about proper gate/ADSR control. Best Regards, Thorsten.

Before continuing with speculations, I think it's better to try out the code modification by myself. Just give me some days to find some time for getting into the firmware again. Using MIOS_DOUT_SRSet directly is no solution, as the MB64 firmware takes control over LED values, and could always overwrite the shift register value (-> MB64_LED_Update) by values derived from MB64_BUTTON_VALUES_SR0, MB64_MBUTTON_VALUES_SR0, etc (depends on LED mapping specified in your midibox64.ini file) If I understood you correctly, you are just searching for a "radio button" function. Is this correct? This is what I tried to program "blind", but as I see, there are too many details we haven't considered. (I programmed this firmware ca. 6 years ago... ;)). Such a usage model hasn't been considered at this time, therefore the implementation isn't straightforward With the C wrapper, and an application built up from scratch, it would be much easier to get total control over buttons and LEDs. What exactly are you planning to do with your MIDIbox? Best Regards, Thorsten.

Which MIDI Interface are you using exactly (manufacturer)? There is an upcoming TEST_INOUT2, which isn't documented yet: Could you please check, if the transfer is working when R6 (1.2k resistor) is replaced by a smaller one, e.g. 470 or 220 Ohm. Note: if you don't want to replace the resistor for this check, you could also connect a 1k in parallel (resulting resistance is ca. 500 Ohm... thats ok for this check) Best Regards, Thorsten.

It's documented in the setup_*.asm file E.g., setup_mbseq_v3.asm, search for "Step" Note that you are able to change the pin assignments as required. Best Regards, Thorsten.

Well, the last step is to prevent, that LEDs will be cleared again when you release the button. Just move the "setf" instruction below the button state check as shown in the (modified) example above Best Regards, Thorsten.

So far I remember, PBrennerNG handles the PIC as a PIC16F84 whenever no ID can be read. Probably because these old chips had no ID at all. It could be, that the MCLR# voltage is not high enough for enabling programming mode, so that the correct ID cannot be read. The error could also be somewhere between the Data IO pin (RB7) and the data out line (Pin #10 of the Sub-D plug) Best Regards, Thorsten.

Danke fuer die Info! Gruss, Thorsten.

Yes, this is truely an original project! Great work! :) Perfect! Best Regards, Thorsten.

Yes, it seems that the LEDs are inverted. Thats no problem, just replace "clrf" by "setf" to set all LED flags (-> which will cause to turn all LEDs off) Best Regards, Thorsten.

Thats correct - if one or more LFO periods have already been processed after the last synchronisation, setting the oneshot flag will cause an immediate stop at phase 255. Just let the oneshot flag set, and if the LFO waveform should be retriggered, set the sync flag, wait for LFO reset, clear the flag. Thats the intended behaviour, and I'm not planning to change this. The previous - wrong - behaviour was related to the right channel flaws (overrun flags located at wrong bit positions) Best Regards, Thorsten.

P.S.: for the planned CS options I will re-organize the "SHIFT" page to an hierarchical menu. This will allow quick access to more flags and functions than today Best Regards, Thorsten.

Nice demo :) Finally I guess that I understand what you mean - the effect itself is well known to me. I'm doing similar things with lead patches --- here we have the advantage that the LFO reset is part of the trigger matrix, so that the waveform can be controlled from any trigger source, not only by the gate. E.g., another LFO, an envelope, MIDI clock, etc... The bassline doesn't provide such a flexibility because of the reduced parameter set. Btw.: you are able to synchronize the LFO rate to the BPM generator (set CSn flag, and use rates >= 245) RC19 is available for download now; ChangeLog: o Enhancements for SysEx Editor (see also doc/mbsidv2_sysex_implementation.txt) - introduced <WOPT> function which allows to change parameters of multiple voices with a single SysEx command - introduced <sids> selection which allows to access slave SIDs via master SID (command 0C 00 <sids>) - added SysEx command for all notes/sequences off (command 0C 08) - added SysEx command to play the current patch (command 0C 09 [<ins>]) Note: for proper handling of <ins>, seperate keyboard zones or MIDI channels for multi instruments are currently required - this is no bug, but just an imperfection (I was too lazy to overwork SID_PATCH_NotesOn yet) o parameter assignment/patch/bank selection: "big message" now displayed immediately when menu item has been selected o The "note off" function of the SHIFT menu now works as "Note On/Off" (called "Ply") This function is intended as replacement for the optional Play button Patch will be played/stopped on all selected SIDs o Removed button combination "SIDx+MENU" (which was previously used for Play function) This combination could get a different purpose in future o LFOs and ENVs of right channel bassline working properly again o AOUT_LC driver now supports 12/12/8 resolution (requires 4 combined 74HC595) [/code] Best Regards, Thorsten.

I forgot to set the bank correctly: [tt] SET_BSR MB64_BUTTON_VALUES_SR0+3 clrf MB64_BUTTON_VALUES_SR0+3, BANKED [/tt] Best Regards, Thorsten.

Consider, that using Oneshot without Sync is an illegal configuration. It could somehow lead to an interesting effect, it could lead to no effect at all, but in general it doesn't make sense to use it this way. I've the impression, that you don't reflect about my statements completely. E.g., I wrote why Oneshot without Sync doesn't make sense, but you are still writing about switching on/off Sync while Oneshot is active in a way, that it isn't clear to me if you want to complain about the behaviour or not. Or another case: I wrote that the right channel bassline is currently flawed, but you continued to report unexpected effects. A discussion on such a basis is very time consuming and not really constructive. Video demos: fine! But please wait until the right channel bassline is working properly again (or use rc17 or earlier). I'm planning to test the java based editor in the next days, and will have some time to work on the firmware again. Best Regards, Thorsten.