TK.

While looking into your mbnet.inc modifications I noticed that you commented out some important stuff, such as: CS_MENU_MBNET_Tx_SendEvent ;; movff CS_MENU_SID, MBNET_SLAVE_ID ; prepare transmission [/code] this will lead to an undefined ID - probably the master will send to any slave, but not to the slave you wanted to address there might be more errors. Best Regards, Thorsten.

as mentioned before, it isn't really required to include cs_menu_mbnet.inc I was only confused about the missing files. Meanwhile I noticed that you added mbnet.inc to include/asm instead of src/ - thats the wrong location, include/asm is normaly copied from http://svnmios.midibox.org/listing.php?repname=svn.mios&path=%2Ftrunk%2Finclude%2Fasm%2F and will never be touched. It would be better if you would work with the original repository... ;) Best Regards, Thorsten.

No, you don't need to include these files, it won't help. I missed mbnet.inc, and thought that you forgot to add other files as well... Yes, but if you made anything wrong (e.g. diode in wrong direction, bad soldering joint), you would see such effects as well. Therefore this assumption... I don't have more explanations for this effect yet. If you would work on a MIOS32 application, I would propose to add some debugging messages sent to MIOS Terminal, e.g. at the location where a new frame is sent, where it is received, where a reply is sent, where the reply is received... but MIOS32_MIDI_SendDebugMessage isn't available for MIOS8. Instead you could debug with MIDI events. E.g., send "B0 00 <any-number>" at interesting locations to get some hints about internal operations. No, I tried it with my Ubuntu installation some time ago, but it wasn't possible to send/receive MIDI messages. This seems to be related to the Juce version that I was using at this time, but I haven't continued debugging in the hope that a Linux expert could solve this. Best Regards, Thorsten.

Hi, yes, this would be possible - I guess that for notes you need a gate input as well? What is the shortest gate pulse which can be triggered by your analog sequencer? And does your sequencer set the gate after CV has changed, or before? What is the estimated delay between these two changes? Best Regards, Thorsten.

Wow, good progress! :) Btw: there is a SVN repository available, see also http://svnmios.midibox.org/listing.php?repname=svn.mios&path=%2Ftrunk%2F I just gave you programmers status - now you've access to a hidden forum section where you can post your SSH key to get write access to the repository. (your .zip file doesn't contain all files, and the file structure is different for application development) Inside the repository, you would simply branch the midio128 application and add your changes there. Since you haven't included the cs_menu_mbnet.inc (and sid_mbnet.inc) file, I'm not sure if the transfer protocol is used correctly. It's important that the slave replies a message, the master will wait for this! And just to ensure: All sent frames must be visible on the Rx pin as well - even the sender must "see" the frame he is sending (for collision detection). See also http://www.ucapps.de/midibox_sid/mbsid_v2_communication.pdf Note that for longer distances between the cores you will need a CAN transceiver at each side! Best Regards, Thorsten.

I will relax the rules, some official words about this topic soon. Of course, you are still allowed to state your opinions ;) Best Regards, Thorsten.

Makes sense, I will add this to the next version. Best Regards, Thorsten.

Great! :) Best Regards, Thorsten.

You could do the same with the matrix approach by implementing some kind of "low pass filter". Just define a global counter, and a second variable which stores the state of the hex switch. u8 hex_switch_counter = 0; u8 hex_switch_state = 0; [/code] In BUTTON_NotifyToggle change the state according to the pin change, and set the counter to a certain value - let's say 50 Don't react immediately on this change (e.g. don't send a MIDI event) Instead, add following routine to TASK_MatrixScan() [code] if( hex_switch_counter ) { --hex_switch_counter; if( !hex_switch_counter) { // counter reached 0 // do something with hex_switch_state... } } In other words: whenever the hex switch changes it's state, wait for 50 mS before doing something with the new state. Best Regards, Thorsten.

Compare http://svnmios.midibox.org/listing.php?repname=svn.mios32&path=%2Ftrunk%2Fapps%2Fsequencers%2Fmidibox_seq_v4%2Fhwcfg%2Fstandard_v4%2F with http://svnmios.midibox.org/listing.php?repname=svn.mios32&path=%2Ftrunk%2Fapps%2Fsequencers%2Fmidibox_seq_v4%2Fhwcfg%2Fwilba%2F Maybe Wilba can give you a schematic for the matrix wiring, I only did the programming ;) Best Regards, Thorsten.

MBSEQ V4 supports up to 3 MIDI INs, more (also IIC based) are technically not possible. See also the schematics: http://www.ucapps.de/midibox_seq_manual_hw.html Best Regards, Thorsten.

Did you know this example project? (the topic name might be confusing, therefore you probably haven't found it - I will change it in future) Best Regards, Thorsten.

First a stupid question: did you upload the right firmware? Only setup_mb6582.hex (and setup_tk2.hex) are configured for the special MB-6582 button/LED matrix. Best Regards, Thorsten.

Yes, this isn't nice... :-/ You could disable the assignment to CC#32 in src/sid_cc_table.inc replace: db 0x2c, 0x2d, 0x2e, 0x2f, 0x48, 0x4c, 0x00, 0x00 ; offset 0x20 [/code] by: [code] db 0x00, 0x2d, 0x2e, 0x2f, 0x48, 0x4c, 0x00, 0x00 ; offset 0x20 Best Regards, Thorsten. P.S.: please check your email inbox ;)

Beta30 is available: MIDIboxSEQ V4.0beta30 ~~~~~~~~~~~~~~~~~~~~~ o added LED and BUTTON functions for TRACK_MODE, TRACK_GROOVE, TRACK_LENGTH, TRACK_DIRECTION page to MBSEQ_HW.V4 file MORPH and TRANSPOSE renamed to TRACK_MORPH and TRACK_TRANSPOSE o added LED and BUTTON function for FAST2, which is a second "fast" button with dedicated button behaviour. In distance to the common FAST button, the button behaviour is configured for push (and not for toggle) mode. The intended usecase is to use this function with push-button encoders. o Echo function: support for "dotted delays": 32d 16d 8d 4d 2d In order to keep existing patterns compatible, they are mapped to parameter value 16..21, but displayed/selected in the right order in the Fx->Echo page. Please note that it isn't a bug that 32d is displayed *after* 16T, 16d *after* 8T etc - the entries are ordered by the resulting delay length! o a "Forward MIDI" option has been added to the record page. Previously events played by an external keyboard were always immediately forwarded to the MIDI output. Now it's possible to disable this function for keyboards w/o a "local off" function. o the quantization of recorded MIDI events is now freely configurable in the Record page. Than lower the percentage value, than lower the quantization (-> events not shifted to the next step) [/code] and now I want to see some happy faces! ;-) Some words to the "dotted" delays: after I noticed that 8d is my most favorite setting for audio delays, the motivation to find a solution got stronger. And there is a compatible solution: values are mapped internally - you will only notice this when controlling the delay from external via CC (or loopback) - see also the doc/mbseqv4_cc_implementation.txt file. And another note: some time ago I started a documentation for the OSC option. This is basically copy&paste of an email conversation: http://www.ucapps.de/midibox_seq_manual_osc.html Some informations are still missing, e.g. how to configure OSC in internal applications such as Reaktor or Max/MSP, and how to use the MIDI proxy to remote-control a MIDI synthesizer via ethernet. I will add this sooner or later... but as I'm still the only one who finds this topic interesting, it's low priority ;) Best Regards, Thorsten.

It doesn't matter in which order Program Change and Bank Change are received - both events will change the patch immediately. Best Regards, Thorsten.

Ooofff.. sometimes you're doing challenging projects ;) Pin #8 and #9 should work as outputs with your initialization routine. I just have doublechecked this on my board. You could measure the voltage directly on the pins of the STM32 chip (see schematic), just to ensure that they are correctly soldered. To the original problem (connect the switch to the scan matrix, first topic of this post): did you already add some debug messages just to check if and when the routine is executed, and what are the results in w/x/y/z on any switch movement? Such messages are really helpful to get a better understanding of the internal processing Best Regards, Thorsten.

Works fine at my side. Note that only values 0..7 lead to a bank change, all other values are silently ignored. You could try the bank change with MIDI-Ox - does it work with this program? You could also check if Sonar really sends CC#0 by using a MIDI-Loopback, monitored with MIDI-Ox Best Regards, Thorsten.

Oh, probably you haven't experienced the Force-to-Scale feature yet, which ensures that the sequencer will never play a terrible note. In distance: by changing a parameter slowly, the audience will hear some interesting variants - always in scale. See this video as an example: (at 2:00 pp) Although I'm not editing steps directly here (I'm using some different LFO/Echo parameters instead which are not supported by MBSEQ V3), but the effect is similar if you live-edit a common sequence. Best Regards, Thorsten.

Hi Markus, Since I find such a usage a bit cumbersome (I wouldn't use it by myself), I would only add such a mode if multiple people request it. Each new mode increases the complexity (and hard to find functions - as you already noticed). Best Regards, Thorsten.

Ok, the next release will provide these button functions (and LED functions as well for people who can't resist to use LEDs for everything) Best Regards, Thorsten.

Hi Markus, congratulations for (almost) finishing your MBSEQ! :) No, such an edit mode isn't supported (and impossible with the PIC based MBSEQ due to very reduced RAM resources). Yes: inside the option page enable the "SyncPatChange" function. It also allows you to specify the measure size (by default 16 steps) Best Regards, Thorsten.

Nils will handle the order. He is currently very busy with his diploma thesis, but it seems that he will finish soon! :) Best Regards, Thorsten.

It's great to have such warnings. E.g., in MBSEQ I had to fixed 100s of warnings (took ca. 1 hour), but I found a potential bug which could happened in the past due to function calls with incomplete parameter list (-> random behaviour) I never noticed this before as I forgot to include the header file into the .c code -> accordingly the C compiler allowed me to pass any parameter w/o producing an error about an "undeclared function" or "inappropriate usage". Due to this experience I decided to enable warnings for everybody. Sorry for the inconvenience - you would really like the change if it would have warned you about *THE BUG* that infrequently happened in the past and that you never reproduced during long debugging sessions before. ;) Best Regards, Thorsten.

Hi, the MIOS8 variant for PIC18F4685 always selects 4bit LCD mode, regardless of the SW configuration - this was the easiest way to avoid that users have to consider this, resp. that special application firmwares have to be released for this derivative. MBNET for PIC: only exists (and only makes sense) in assembly language: http://svnmios.midibox.org/filedetails.php?repname=svn.mios&path=%2Ftrunk%2Fapps%2Fsynthesizers%2Fmidibox_sid_v2%2Fsrc%2Fmbnet.inc For MBHP_CORE_STM32 a C based variant (customized to the CAN interface of STM32) exists: http://svnmios.midibox.org/listing.php?repname=svn.mios32&path=%2Ftrunk%2Fmodules%2Fmbnet%2F It isn't possible to adapt this library to a 8bit controller Best Regards, Thorsten.