TK.

Beta31 is available now: MIDIboxSEQ V4.0beta31 ~~~~~~~~~~~~~~~~~~~~~ o a powerful session import/export function has been added. It allows you to copy one or multiple patterns to any session location. Both functions are available in the Utility->Disk page o "Save as.." shows the current session name as default name [/code] Snapshot of the new pages: and and I really missed this! :) Best Regards, Thorsten.

yes, I could simply add a range, but this also means that I will have to restructure the CV configuration page which is a bit time consuming :-/ If you want to change all patterns at once, just use the Phrase feature (-> song page) It allows you to predefine 16 sets of patterns (but also mutes, tempos, mixer pages, etc) and to "fire" them with the GP buttons. Best Regards, Thorsten.

It is impossible as the PIC18F84 has no internal UART Best Regards, Thorsten.

I tried this some time ago, but it was too complicated. Especially gsim didn't behave like expected, so that I gave up! :-( I'm not able to try MPLAB as it doesn't run on a Mac, but as mentioned before: the setup will be very complicated! Best Regards, Thorsten.

There are already available applications which use OSC, such as: http://svnmios.midibox.org/listing.php?repname=svn.mios32&path=%2Ftrunk%2Fapps%2Fexamples%2Fethernet%2Fosc%2F and http://svnmios.midibox.org/listing.php?repname=svn.mios32&path=%2Ftrunk%2Fapps%2Fmisc%2Fusb_osc_midi_cv_proxy%2F I also started a documentation (for MBSEQ V4, but it's valid for other OSC applications as well): http://www.ucapps.de/midibox_seq_manual_osc.html Note that your friend is wrong, OSC isn't more low-cost (performance and pricewise) Best Regards, Thorsten.

In USER_MPROC_NotifyReceivedEvent you could check if the CC has been received and set all J5 outputs to 0 in this case. It might be easier for you to implement this in C Best Regards, Thorsten.

Note that sammichSID is already a fully hackable DIY synth, it's open source, it's easy to build. So, the idea itself isn't really new, although some websites (which mostly take Arduino based designs as basis) promote this as something new and special... We go this way since more than 10 years. ;) A digital STM32 based synth in a sammichBox would be nice of course! :) Best Regards, Thorsten.

It would be better to add a second core for such a purpose, because the original MBSEQ V4 application has no free pins for that. So: just use a second STM32 which scans and converts the 96 analog inputs and passes it to the second core via MIDI. Best Regards, Thorsten.

Very nice tune indeed! Blogged :) Best Regards, Thorsten.

Please also ensure that the Mono switch is not enabled in your ensemble setup. See also: http://www.ucapps.de/midibox_sid_manual_e.html The drum patches are made for 6 oscillators (stereo setup), with Mono switch enabled they cannot be played correctly as only 3 oscillators are available. Best Regards, Thorsten.

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.