TK.

Concerning the integration into the existing firmware: I could provide a special hook for button events, and another one for LED updates of this 4x16 matrix, where you could add your own code. So, basically you could keep your customizations in a single file, and migrate to future versions without conflicts. To the changed UI: keep in mind, that many pages require 16 GP encoders !and! 16 GP buttons. The upper row of your matrix would take over this GP functionality in most pages, only in the EDIT page the upper row could be used to set triggers. Since this alternative usage is not optimal, I would propose to add the common 16 GP button row like on the standard UI - otherwise you will really miss it. General question: did you use your MBSEQ yet, so that you know how the standard UI is working? If not, it makes sense to build a cheap version (with some mini buttons and low-cost LEDs) first to get a better understanding of the control surface before building a dedicated one which may miss some important functions. Best Regards, Thorsten.

Hopefully Philetaylor will read this post, he did some experiments with DMX on an LPC17 core some time ago. Best Regards, Thorsten.

Any MacOS should be the preferred choice for debugging (if you are able to run this OS), for MIDI it's the most robust solution. Anyhow, I still believe that this issue is related to a connection problem. Unfortunately I'm currently not at home, otherwise I could create some snapshots from my scope to give you some reference waveforms... Let's try to describe the expected waveforms verbally: the CAN communication will only work if at least two nodes are connected to the bus. The node which sends a CAN frame expects that all other nodes send an acknowledge pulse (I'm speaking about the physical layer, and not the MBNET layer, where ACK has a different meaning...) So, if the sender doesn't get the acknowledge pulse at the end of the frame, it will retry automatically... and give up after a certain number of retries and go into Bus Off state, where it does't send anymore until re-initialization. It could be, that the re-initialization currently only takes place after an application reset, I haven't checked this at my side yet (and won't be able to check this in the next week...) What is expected on the scope: all Rx pins should always show the complete CAN frame (let's say: a lot of pulses...) The Tx pin of the sending node should show almost the complete CAN frame as well... Just the last pulse - the ACK - should be missing. The Tx pin of the receiving node should be idle (logic-1) while the other node sends a frame. But at the end of the frame it should send the ACK pulse. It's very easy to debug this with a 2 channel scope, just probe both Tx pins - and alternatively one Tx and one Rx pin (do you need further descriptions, or is it already clear enough?) Best Regards, Thorsten. Sorry, iPad removes the linebreaks :-(

I tried the same slave node range, and it still works at my side. To the debug messages: what kind of computer are you using? On a Windows PC MIDI can get unstable if only the M$ device driver is used. With MacOS the communication is very stable. Beside of me, you are the only guy who tried MBNET yet, so that I haven't enough experiences what could go wrong at the user side. As far as I can say, the described behaviour indicates a hardware connection issue. Check that D1 is soldered in the right direction, and that R11 is mounted. It could make sense to remove R11 on one board, because actually the so called "Wired AND" should only have a single pull-up resistor. See also this schematic, how the CAN interfaces have to be connected for multiple PICs: http://www.ucapps.de/midibox_sid/mbsid_v2_communication.pdf So, at my side it works with R11 connected on both boards (so that the resulting resistance is 500 Ohm instead of 1k), but it could be that the lower resistance reduces the signal level so much, that the communication is failing at your side. Best Regards, Thorsten.

This is the most simple example: http://svnmios.midibox.org/filedetails.php?repname=svn.mios32&path=%2Ftrunk%2Fapps%2Fcontrollers%2Fmidibox_ng_v1%2Fcfg%2Ftests%2Fblm8x8.ngc For your HW connections, you've to change the DIN/DOUT matrix configuration to: DIN_MATRIX n= 1 rows=8 inverted_sel=0 sr_dout_sel1=1 sr_din1=1 DOUT_MATRIX n= 1 rows=8 inverted_sel=0 sr_dout_sel1=2 sr_dout_r1=3 Best Regards, Thorsten.

"Acknowledge" could be confusing here, because actually we've two different types: the ACK of the CAN hardware protocol (and was writing about this one), and the ACK of the MBNET software layer. However, I wrote a small demo application to test the communication between two cores by myself. I noticed, that the wrong pinning was selected in modules/mbnet/LPC17xx/mbnet_hal.c, did you notice this as well? If not, then we know why it didn't work. The default selection is for the MBHP_CORE_LPC17 board now. I also added some support functions for the MIOS Terminal to simplify debugging. Please update your repository. The new demo application can be found under apps/examples/mbnet Debug messages are enabled by default (verbose level 3). After startup the application will scan for available nodes between ID 0x00..0x07 (configured in mios32_config.h) Enter "help" for available commands: [16602.262] Welcome to MBNET Example! [16602.262] Following commands are available: [16602.262] mbnet: prints status informations [16602.262] mbnet_reconnect: (re-)scans for MBNET nodes on the bus [16602.262] set mbnet_id <0x00..0x7f>: changes my MBNET ID (current ID: 0x10) [16602.262] set mbnet_verbose <0..4>: enables MBNET debug messages (verbose level: 3) [16602.263] reset: resets the MIDIbox (!) [16602.263] help: this page E.g. with "mbnet" I'm getting: [16643.012] mbnet [16643.014] My MBNET ID: 0x10 [16643.014] MBNET State: running [16643.014] MBNET Scan State: finished [16643.014] Slave # 1: not found [16643.014] Slave # 2: not found [16643.014] Slave # 3: not found [16643.014] Slave # 4: not found [16643.014] Slave # 5: ID 0x04 P:1 T:ABCD V:1.0 [16643.014] Slave # 6: not found [16643.014] Slave # 7: not found [16643.014] Slave # 8: not found [16643.014] MBNET Verbose Level: 3 I'm using two instances of MIOS Studio, connected to the two cores. The MBNET ID of the second core has been changed via "set mbnet_id 4" Then I entered "mbnet_reconnect" on the first core: I also tested the communication with a MBSID V2 (PIC based), and it works: [16937.869] mbnet [16937.872] My MBNET ID: 0x10 [16937.872] MBNET State: running [16937.872] MBNET Scan State: finished [16937.872] Slave # 1: ID 0x00 P:1 T:SID V:2.0 [16937.872] Slave # 2: ID 0x01 P:1 T:SID V:2.0 [16937.872] Slave # 3: ID 0x02 P:1 T:SID V:2.0 [16937.872] Slave # 4: ID 0x03 P:1 T:SID V:2.0 [16937.872] Slave # 5: not found [16937.872] Slave # 6: not found [16937.872] Slave # 7: not found [16937.872] Slave # 8: not found [16937.872] MBNET Verbose Level: 3 So, I guess that it should work properly at your side as well... Best Regards, Thorsten.

Hi, thanks for the compliments! :) Just copy the subdirectories of the SESSIONS directory to the new SD Card (e.g. by using a SD Card reader) Btw.: this way, you can also create backups of your sessions. Under Utility->Options->5 you will find the function "Dump a predefined Mixer Map on Pattern Changes", this would help at least for pattern changes. But I guess that it won't send when you press the Play button. I could add this option to the next release. I've to check this at my side. I haven't stressed the MIDI router that much in the last months. I'm mainly using it to upload firmwares to core modules which are connected to MIDI IN/OUT; this kind of bidirectional SysEx transfer is working without errors. Hopefully I can reproduce this by sending some SysEx dumps to various synths. Best Regards, Thorsten.

Permanent off state will be reached if one core tries to send messages to another core and doesn't get acknowledges. Depending on the number of missed acknowledges, it will first go into error passive, and later into bus off state where no message can't be sent anymore until the CAN peripheral will be re-initialized. You won't find this handling in the mbnet driver, because it's implemented in the CAN peripheral (based on the CAN spec, see: http://esd.cs.ucr.edu/webres/can20.pdf chapter 7 "Fault Confinement") What does this mean: the execution of MBNET_Handler() should be delayed by 2..3 seconds after power-on to ensure that all CAN nodes are ready and could acknowledge incoming messages. In addition, it makes sense to add a way to re-initialize the CAN if it goes into bus-off state (you already noticed, that this helps) For example, in the MBSID V2 firmware the CAN will be re-initialized, if the user pushes one of the SID buttons while CAN is in busoff state. This also re-starts the scan for MBNET nodes -> hot plug & play! :) Best Regards, Thorsten.

You will probably see this lower voltage when the MIDI OUT port is connected to the MIDI IN of your MIDI interface, is this the case? If you disconnect the MIDI cable, you should measure 5V, right? Concerning the failing "TEST MIDI2": what happens, if you connect the RX Pin to J12:M- (this would bypass R7) Best Regards, Thorsten.

Ok, now I know from where the confusion is coming from... ;-) The special divider mentioned in the user manual doesn't exist anymore... I just have removed it from the documentation, and improved the examples. For 50 Hz you want to step the WT or ARP each 20 mS. At 124 BPM (= 5 mS per tick), you could achieve this by setting the speed to 4 Alternatively, you could clock the WT from an LFO with a constant frequency: go to the "Clk" trigger, and disable the connections for W1S, W2S, W3S, W4S Then go to the L1P trigger (or whatever LFO you want to use) and enable the connections there. Best Regards, Thorsten.

Hi, since the PIC reboots, it's very likely that it receives the SysEx commands which have been sent by MIOS Studio. Only the PIC MIDI OUT -> Mac MIDI IN path seems to be problematic. Since "TEST PC1" is working, an incompatibility issue with your MIDI interface is unlikely. I would continue with the core tests Best Regards, Thorsten.

Hurray! :-) Is the communication with MBSEQ V4L working at your side? Best Regards, Thorsten.

I don't remember all the details of this v1 firmware which has been developed more than 10 years ago, but from the source code it seems that the rate is multiplied by 2, and not 3 as you mentioned. This is what I wrote in the documentation (-> http://www.ucapps.de/howto_sid_wavetables_1.html) So: could you please try 115? The resulting rate will be 19.67 mS = 50.89 Hz, but I hope that you are happy with this setting anyhow. because you only increment and decrement values, you never start with an absolute value. This won't work. And therefore the first sequence (40 +18 -0c -0c) was better. Do you know these tutorials? -> http://www.ucapps.de/howto_sid_wavetables_1.html -> http://www.ucapps.de/howto_sid_wavetables_2.html -> http://www.ucapps.de/howto_sid_wavetables_3.html Especially in the third page it's mentioned again, how to select ca. 50 Hz - so, probably you will find much more new informations there ;) Best Regards, Thorsten.

I hope that I found a good name for the new item - please try it :) -> http://www.ucapps.de/mios32/midibox_seq_v4_079_pre1.zip Best Regards, Thorsten.

The latched values are now reseted after a pattern change, this hopefully avoids this problem. -> http://www.ucapps.de/mios32/midibox_seq_v4_079_pre1.zip Best Regards, Thorsten.

You are right, it would also be possible to provide the global intensity control at the groove page. It's unlikely that another parameter will be added to this page, therefore position 7/8 are free for this purpose. Note that this won't be an additional parameter, but just a shortcut to change the intensity parameter of all tracks at once. Is this acceptable? Best Regards, Thorsten.

I come to the conclusion, that this issue is matching with - MIDI monitor logs shows exactly the same behavior (rapid note on/off toggles) - D7 triggers MIDI events - SI input is working Geth fixed this by re-soldering every connection of the core module. I think that it should be sufficient to re-solder all pins which go to/come from IC1 (74HCT541) Especially J8/9 SC & RC1/2, Pin #12/13/14 of IC1, Pin 7/8/9 of IC1, P0.9, P0.7, P0.6 of the LPCXPRESSO. Maybe also the power related lines (Vs/Vd) to J8/9 Best Regards, Thorsten.

but you get a MIDI event whenever a ground connection is done (and removed)? Just like if you would push a button? I forgot to mention, that the DIN module should not be connected for this test. However, the result is like expected. You notice this, when DIN module is connected, right? What happens if the DIN module is not connected, and you repeat this test? And please also do the test with the single 74HC165, because it seems that with a single chip no continuous note off/on will be generated, right? Or does this mean, that they won't be generated if all digital inputs (D0..D7) are connected to ground? Best Regards, Thorsten.

Probably the "Touchsensor Sensitivity" is too low. I think that 3 is the best value. Change it - and if it works, push the "send" button to ensure that this configuration is permanently saved (and will be restored after power-on) Once you get the touch sensors working, I strongly recommend you to select the touch sensor mode which ensures that no fader event is sent as long as the sensor is not pressed (last option) General hint: than lower the motor voltage (can be adjusted with P1 on the MBHP_MF_NG module), than quieter the faders. For Alps RSAON the default Duty settings (48/64) are ok for both directions. PWM Steps should be 64. These are the default values... Adjust the motor voltage, starting from the lowest value, increase the voltage until all faders are moving and don't get stucked. The "Slow Sine" testmode is very useful for this procedure. Best Regards, Thorsten.

Alright, this was some kind of "unwritten rule"! In order to ensure, that somebody else won't be blocked by the same issue, I added following comment to all existing Makefiles: # common make rules # Please keep this include statement at the end of this Makefile. Add new modules above. include $(MIOS32_PATH)/include/makefile/common.mk Best Regards, Thorsten.

@Stuartm: the big question is, in which page such a global parameter should be made accessible. Since your request really makes sense (because unequal intensity settings in the tracks result into unwanted delay differences), I could also change it that way, that the intensity parameter is always changed to the same value for all tracks. And if somebody doesn't like this handling, it could be optionally disabled in the (new) Options page (available with V4.078), which allows to add more customization flags without much effort at my side in future. @MusicCircus: I guess that your questions have been answered in meanwhile. Ok, back to topic: I think it makes sense to release the changes that I did ca. 1..2 months ago - have fun! :smile: MIDIboxSEQ V4.078 ~~~~~~~~~~~~~~~~~ o removed MSD (mass storage device) mode to save some memory. With the MIOS Filebrowser (integrated into MIOS Studio) this mode has a good replacement meanwhile. For direct access to the SD Card another application (like MIDIO128) could be temporary uploaded... or the SD Card can be plugged into a common SD Card reader. o Options page has been overworked, so that more options can be added in future o experimental: if Live mode or a MIDI Router based "Track" or "Sel.Trk" is active, and Note, CC, PitchBender, Program Change is received on the selected IN Port, the corresponding track layer (or LFO CC) will be muted completely, or temporary for a given number of steps. This allows to temporary overrule events generated by the sequencer from an external MIDI keyboard or controller. This feature has to be configured in the UTILITY->Options page, it's disabled by default! o activate the ALL function (press ALL button) in the mute page to get a new menu page which allows to mute/unmute all tracks, layers of current track or mute&layers of all tracks. Sidenote: this obsoletes the UTILITY->MUTE and UNMUTE function, which might be replaced by something else in future. o the 6 new mute/unmute functions are now also accessible from dedicated buttons (and LEDs). They have to be assigned in the MBSEQ_HW.V4 file. o it's now possible to control the track mutes via CCs. The first CC (for the first track) has to be configured in the MENU->MIDI->Ext.Ctrl page. The remaining tracks are controlled from the 15 consecutive CCs. E.g. if the CC number is set to 16, the mutes of track 1-16 are controlled with CC#16 .. CC#31 o it's now possible to dump a mixer map via CC. The CC has to be configured in the MENU->MIDI->Ext.Ctrl page. o a CC assigned to a sequencer layer won't be sent if it's also assigned to the LFO "Extra CC" o if a track is initialized, CC layers will be assigned to "off" by default (no CC will be sent). The desired CC number has to be set explicitly before a CC layer will send an event. o in record mode, incoming CC events will be automatically assigned to free CC layers so that no pre-configuration is required (like known from MBSEQ V4L). A CC layer is "free" (unassigned) as long as the CC number is turned "off". This is the default setting for all CC layers after initialisation, and can be changed in the MENU->EVENT page if desired. o Trigger/Layer/303 edit view working again Best Regards, Thorsten.

Hm... let's do some additional checks: - what happens if all 74HC165 are removed? Expectation: no MIDI events should be sent - what happens if only the first 74HC165 is plugged into the socket? Expectation: MIDI events for the first 8 pins should be sent whenever D0..D7 inputs at J3 are grounded. No continuous toggles should be generated. - what happens if the DIN module is connected, and J8/9:SI is directly connected to Vs (ground) with a short wire? Expectation: once you connect the cable, many Note On events should be sent, but only once. Thereafter no additional events should be generated anymore. Once you disconnect the cable, many Note Off events should be sent, but again only once. No repeating note on/off... Best Regards, Thorsten.

Could you please type "make clean" And then "make" again? Maybe there is some kind of artifact in the project_build directory which leads to this effect. Best Regards, Thorsten. P.S.: "make clean" will just delete the project_build directory...

Hi, what is the content of your midi_filters.mk file? It should be something like: C_INCLUDE += -I $(MIOS32_PATH)/modules/midi_filters THUMB_SOURCE += \ $(MIOS32_PATH)/modules/midi_filters/midi_filters.c Best Regards, Thorsten.

In MIOS8, each analog conversion will take 200 uS, accordingly 64 inputs can be scanned within 12.8 mS This might be sufficient for an organ keyboard, but you've to try it out. MIOS32 in conjunction with the MBHP_AINSER64 module and the MBNG firmware won't be much faster (ca. 10 mS for 64 inputs), because the driver isn't optimized for higher speed. In theory a faster conversion would be possible, but this would require a different firmware. Best Regards, Thorsten.