TK.

I could implement the support for a CV In + gate input This isn't available yet, but you asked if it is possible, and technically it is possible. no (no free pins to control the MUX) currently only http://www.midibox.org/dokuwiki/doku.php?id=acsensorizer But this MIDIbox can do much more than you've requested ;) probably yes, but this application is quiet old and only supports ca. 20% of MBSEQ V3 features, and 5% of MBSEQ V4 features ;) On the other hand: you could build a MBSEQ V2 and MBSEQ V4 and synchronize them via MIDI clock. Best Regards, Thorsten.

CS_MENU_SID is a variable of the MIDIbox SID application, it's normaly not part of mbnet.inc - you added it from somewhere else... Instead of: which is doing the same w/o the usage of a temporary variable. Or you could even remove the "movlw" (loading constant value into WREG): CS_MENU_MBNET_Tx_SimpleSend SET_BSR MBNET_SLAVE_ID movwf MBNET_SLAVE_ID, BANKED [/code] and initialize WREG before calling CS_MENU_MBNET_Tx_SimpleSend [code] ;; send something to slave #0x01: movlw 0x01 call CS_MENU_MBNET_Tx_SimpleSend which gives you more flexibility (and doesn't require the CS_MENU_SID variable anymore. You can use call MIOS_MIDI_DeviceIDGet [/code] to determine the device ID of the core on which the application is running. See also http://www.ucapps.de/mios8_fun.html#MIOS_MIDI_DeviceIDGet I don't see the reason why it shouldn't be possible to add the transmit code to USER_MPROC_NotifyReceivedEvent E.g., try following code (untested - just to give you the idea - if it doesn't work, first try to debug this by yourself!) [code] USER_MPROC_NotifyReceivedEvent ;; master forwards MIDI events to slaves movff MIOS_PARAMETER1, TMP1 ; MIOS_MIDI_DeviceIDGet overwrites MIOS_PARAMETER1, therefore we temporary store it in TMP1 (such dependencies are the disadvantage of assembly language... :-( - but still easier to handle than a stack) call MIOS_MIDI_DeviceIDGet movff TMP1, MIOS_PARAMETER1 ; restore MIOS_PARAMETER1 bnz USER_MPROC_NotifyReceivedEvent_S ; fortunately "movff" doesn't change the ZERO flag - branch if return parameter of MIOS_MIDI_DeviceIDGet not 0x00 USER_MPROC_NotifyReceivedEvent_M ;; copy MIDI event into MIDI_EVNT[01] and _VALUE movff MIOS_PARAMETER1, MIDI_EVNT0 movff MIOS_PARAMETER2, MIDI_EVNT1 movff MIOS_PARAMETER3, MIDI_EVNT_VALUE ;; send to MBNET movf MIOS_PARAMETER1, W andlw 0x0f ; MIDI channel located at MIOS_PARAMETER1[3:0] addlw 1 ; add +1, we don't want to send to the master... -> MIDI channel 0 (counted from 0) sends to slave 0x01, or in other words: MIDI channel #1 (counted from 1) sends to slave with device ID 0x01 call CS_MENU_MBNET_Tx_SimpleSend ; we assume that CS_MENU_MBNET_Tx_SimpleSend copies WREG into MBNET_SLAVE_ID return ; finished USER_MPROC_NotifyReceivedEvent_S ;; so something else here return ; and finish Now you can decode the MIDI event at the slave side -> up to 16 slaves can be controlled this way, and each slave has an individual coding for up to 128 inputs and 128 outputs For forwarding MIDI events just enable the integrated MIDI merger. And a last hint: if your CS_MENU_MBNET_Tx_SimpleSend function would already use MIOS_PARAMETER[123] instead of MIDI_EVNT* variables, the copy operations at the beginning of USER_MPROC_NotifyReceivedEvent are not required - as MIOS_PARAMETER[123] are predefined for all MIOS applications, this makes your function more portable. Best Regards, Thorsten.

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.