TK.

A very helpful demonstration of the effects, Matrigs! :) My first impression: it sounds like a logical defect inside the SID chip, because no parts of the firmware which could "bend" the sound output so much. On the other hand: while reading your previous posting, it isn't clear if you already fixed the 74HC595 issue. If there are shorts or bridges or faulty connections which can cause an improper logical level (should be either 0V or 5V +/- ca. 0.3V), the SID won't "receive" correct data and will output random sounds - or nothing. Like demonstrated in your MP3 Best Regards, Thorsten.

For MBLC: you only need to invert MIOS_PARAMETER2 within the USER_DIN_NotifyToggle function, before it branches to LC_BUTTON_Handler This can be done with "comf MIOS_PARAMETER2, F" Best Regards, Thorsten.

When I read your initial question, I guess, that the 0x40 was confusing you. The 8th and 9th byte are the address, 0x4000 means: BankStick, offset 0 Best Regards, Thorsten.

When you are starting at the 12th, and not at the 13th byte, it makes sense: First 8 bytes of BankStick content: 0x04, 0x4b, 0x53, 0x2d, 0x35, 0x2f, 0x30, 0x39 Binary representation: 00000100 01001011 01010011 00101101 00110101 00101111 00110000 00111001 Scrambled SysEx Stream: 0x02 0x12 0x6a 0x32 0x69 0x54 0x5e 0x30 0x1c 0x4c 0x06 Binary representation: 0000010 0010010 1101010 0110010 1101001 1010100 1011110 0110000 0011100 1001100 0000110 Now we concatenate the binary values to a single string (remove spaces) 00000100010010110101001100101101001101010010111100110000001110010011000000110 And split it into 8bit chunks: 00000100 01001011 01010011 00101101 00110101 00101111 00110000 00111001 ... Convert it back into hex (or decimal) values: 0x04 0x4b 0x53 0x2d 0x35 0x2f 0x30 0x39 Surprise! ;) Best Regards, Thorsten.

Doublepost http://www.midibox.org/forum/index.php/topic,10842.0.html

No - did you already follow the DIN troubleshooting guide? -> http://www.midibox.org/dokuwiki/din_module please ignore these files, they are part of the release package by accident. They won't work with the current firmware anymore. Please use the released presets, which can be found at the MIDIbox FM page It's described in the README.txt of preset_patches_20050212.zip Where did you found the addressing A/B/C? No, A0..A2 are three address selection input. There are 8 possible combinations for 8 possible addresses Each BankStick requires a unique address, otherwise the firmware won't be able to access any. It could even crash! See also the MBHP_BANKSTICK page for a schematic which describes the different address configurations Maybe this info already helps you to solve the issues Best Regards, Thorsten.

Enjoy the show! :) Z3d6U9ahh_E

So, it's installed under /usr/local/bin now, I guess you already doublechecked this? And the permissions are set properly, so that your user account can execute the file without sudo? You checked that $PATH contains /usr/local/bin? That I don't know, what else could be the reason... :/ Normaly the installation is really straightforward... Best Regards, Thorsten.

Oh yes, of course! So, the firmware wasn't working, because it wasn't completely programmed into the flash. Random things can happen then. It's also possible, that the upload errors happened because the firmware image was corrupted before (this explains, why the testtone app upload wasn't successfull) Just to highlight it again: random things can happen then - things which are hard to diagnose via remote ;) A corrupted firmware upload can be "repaired" the following way: reset the box, and upload the firmware via first level bootloader (so, start the transfer within 2 seconds after power-on) This should give you a clean upload. Not really, because if the application upload wasn't stable, it could be an issue with your MIDI interface. What happens when you are doing the hardware-loopback test. I mean: loopback MIDI Out to MIDI In of your PC, and use MIDI-Ox to send&receive the .syx file The SysEx tool of MIDI-Ox provides a compare function, which allows you to check the equivalence of the sent and received SysEx dump If MIDI-Ox prints mismatches, you know that there is something wrong with the MIDI interface/ MIDI driver/ MIDI cable... Best Regards, Thorsten.

The term "counter" could be missleading, it actually means: SysEx block size / 8 It's normaly the same for all blocks. 256 byte blocks are usually prefered, this results into a "counter value" of 0x100 >> 3 = 0x20 Best Regards, Thorsten.

[quote]i ve downloaded the mpasm2gpasm.pl script but i don t really understand what to do with it, not even if it is necessary[/quote] Haha! No, you don't need this script to get gpasm running ;) Installing the GPUTILS package is sufficient, but it seems that the installation wasn't successfull. The message [code]make: gpasm: Command not found[/code] tells you, that the command shell cannot find "gpasm" (which is part of the gputils package) How did you install the package, and could it be, that you overlooked more error or warning messages? Best Regards, Thorsten. [/code]

Is it working now? Best Regards, Thorsten.

I tried it (change in synch behaviour when song mode is active is already available under http://svnmios.midibox.org/trunk/apps/sequencers/midibox_seq_v3/src/seq_core.inc), but faced unexpected conceptional issues with the way how song and phrase mode is implemented. E.g., phrase mode is just "not song" mode. It isn't possible to provide loops within phrases without redefining the user interface. The purpose of phrase mode is to quickly select a set of patterns (and mixer map), but not to run the song sequencer... More relevant is the way, how the sequencer handles song entries. On each transition, it either changes the pattern, or it disables the pattern. There is no possibility to tell the sequencer, that a newly selected pattern shouldn't be touched. This wasn't required in the past, and therefore hasn't been considered in the concept... So, some extensive changes would be required to get your "quick idea" working, which could cost me one or two days - some effort I don't want to spend so long I don't need such a feature by myself. Note that your idea wasn't straightforward, and a (german) "Bastelloesung" anyhow, this just assures my oppinion, that there should be better solutions - still waiting for the perfect idea which only requires two or three extra assembler instructions! ;) Best Regards, Thorsten.

Yes, really great idea! :) Btw: the midibox_sid wiki page is totally outdated, there are a lot of references to MIDIbox SID V1 related pages, and no references to the new stuff. So, it could be confusing for newbies. Best Regards, Thorsten.

When I say "crash", I mean: anything can happen I won't reply anymore before you've fixed the CAN connection. Best Regards, Thorsten.

Yes, of course, otherwise the CAN bus won't work, and the MBSID application could crash. You are using MIDIbox SID V2, and it runs on a PIC18F4685, no? Best Regards, Thorsten.

It's strange that it shows up in the main menu without an entry in CS_MENU_TABLE_L_ROOT - or did you forget to mention this? Maybe the ID values are not matching with the order in CS_MENU_TABLES_L anymore? Best Regards, Thorsten.

Hi Andy, merging MIDI streams is already possible with the integrated router (see http://www.ucapps.de/midibox_seq_manual.html) Best Regards, Thorsten.

So, issue 3a) of http://www.ucapps.de/midibox_sid_manual_ki.html Sinesurfer: just three days ago I warned about the old MIOS Studio version in the 808 forum! ;-) Best Regards, Thorsten.

The voltages are fine, and if you hear the testtone you are almost done :) Maybe it's one of the issues listed here? http://www.ucapps.de/midibox_sid_manual_ki.html It could be related to 3a) 3b) 3c) or 7) Best Regards, Thorsten.

Well, thats the big advantage of the bit-banging method, because you can copy the MIOS_IIC* routines into your application, (rename the functions and variables to avoid label collisions), and assign different pins to SDA and SCL See also the source code http://svnmios.midibox.org/trunk/mios/mios_iic.inc You will notice, that the code is very small, biggest part of the file is the documentation ;) The number of IIC busses is only limited by the number of free pins - the integrated peripheral doesn't provide such a flexibility (thats another reason why I ommited it...) Best Regards, Thorsten.

It isn't really an CPU architectural issue, it's more a side effect caused by the way how GPIO SFRs are handled. The same issue exists for 8051 derivatives with single-cycle execution, and so far I remember also for AVRs. It doesn't exist in microcontrollers which insert wait cycles during a read access, or which handle masked RMW operations internally in the GPIO stage. It's one of the first things you will notice when toggling a pin as fast as possible with "bsf/bcf" instructions - the pin won't toggle due to the FF at the input stage. You have to insert a NOP (or a more useful instruction) between bsf/bcf --- or you have to write into LATx instead of PORTx (if available) However, modern controllers always provide a seperate IN and OUT register for GPIOs :) Best Regards, Thorsten.

. o O ( und schon wieder ein MBSEQ Anwender mit diesem Problem ) Danke fuer den Input! Somit scheint Seppoman's Vorschlag wohl wirklich weiterzuhelfen :) Gruss, Thorsten.

Clever!!! Gruss, Thorsten.

I re-created the group, therefore it's probably working now :) Best Regards, Thorsten.