TK.

That's a mistake at my side, I've to consider this flag in MBNG_MATRIX_DOUT_PinSet as well. Best Regards, Thorsten.

Some words from my side: I always found the capabilities of RTP-MIDI very attractive, but refused to implement it natively into MIOS32 because of the high amount of engineering effort for a proper implementation of the RTP and Bonjour protocol. Also the resource requirements (especially RAM and fast response time) are so high, that it was clearly something which can't run in parallel to a typical MIOS32 application like MIDIbox SEQ or MIDIbox NG -> definitely something that has to be offloaded to a second core. I was highly interested on the KissBox OEM after Benoit contacted me (actually because of a different project, but we quickly changed the topic ;-), he sent me a sample PCB, and in the last days we worked out a high performance communication protocol for MIOS32 based cores, which works stable. For those who are interested: the driver is implemented in mios32_spi_midi.c: http://svnmios.midibox.org/filedetails.php?repname=svn.mios32&path=%2Ftrunk%2Fmios32%2Fcommon%2Fmios32_spi_midi.c The KissBox is connected to the core via J16. It shares the port with a SD Card (almost no disadvantage), and since there is no hardware conflict, it will be available for all MIOS32 applications in future. Note, that the KissBox OEM also supports an alternative firmware for UART based MIDI ports. This means, that you could upgrade other MIDI devices as well (e.g. MBHP_CORE based -> just connect the Rx/Tx lines to J11) In this case the connection will be slower (just the common MIDI baudrate), but the network based approach still has advantages. Main advantages (from my point of view): in distance to UART or USB based MIDI, a device can contact any other device over a single cable, and transmit with an extremely stable timing. E.g. after experimenting with KissBox I believe that RTP MIDI is the best way to distribute a MIDI clock to multiple computers (and MIDIboxes of course ;-) Better than OSC, especially on a WiFi connection due to guaranteed transmission in the expected order thanks to TCP/IP (instead of UDP) -> no danger for hanging notes! Seamless integration with MacOS, iOS but also Windows computers thanks to Tobias Erichsen's driver in distance to CopperLAN (we had a discussion on this in another thread), the RTP MIDI protocol isn't a closed source protocol which needs proprietary drivers Benoit hasn't mentioned this, but KissBox is ready for HD MIDI, and MIOS32 based devices will probably be the first ones which support the upcoming standard! :smile: Best Regards, Thorsten.

Hi Andy, I can confirm, that J3:RC1 and J3:RC2 are swapped on the V1 AINSER64 PCB due to a layout error. That's correct, and this is the way it should work. How long are the cables? Each cable shouldn't be longer than ca. 10..20 cm! Best Regards, Thorsten.

Step by Step... ;) Best Regards, Thorsten.

Yes, the data lines should be ok. I checked this against this interconnection diagram: http://www.ucapps.de/midibox_seq/mbseq_v4_interconnections_lpc17.pdf Best Regards, Thorsten.

Following version should fix the WT SysEx issue, please try it at your side: http://www.ucapps.de/mios/midibox_fm_v1_4h.zip Best Regards, Thorsten.

Just wanted to troubleshoot the MBFM firmware, but I've the same problem. I'm getting following error message under MacOS and Linux: Exception in thread "main" java.lang.UnsupportedClassVersionError: ui/MainWindow : Unsupported major.minor version 51.0 Version under MacOS: java version "1.6.0_65" Java? SE Runtime Environment (build 1.6.0_65-b14-462-11M4609) Java HotSpot? 64-Bit Server VM (build 20.65-b04-462, mixed mode) And under Linux (Ubuntu): java version "1.6.0_27" OpenJDK Runtime Environment (IcedTea6 1.12.6) (6b27-1.12.6-1ubuntu0.12.04.2) OpenJDK Client VM (build 20.0-b12, mixed mode, sharing) Best Regards, Thorsten.

I agree with Hawkeye, that such a control surface unfortunately doesn't fit with the MBSEQ V4 concept. A new application has to be developed for this, e.g. based on this tutorial: http://svnmios.midibox.org/listing.php?repname=svn.mios32&path=%2Ftrunk%2Fapps%2Ftutorials%2F017_sequencer%2F My sparetime is too limited for such side-projects (which I'm not used myself), but maybe somebody else with programming skills is interested? Best Regards, Thorsten.

Very nice! Could you guys please document this case built in the Wiki? I guess that the .svg files would also be interesting for other users! :) Best Regards, Thorsten.

yes, you are right. yes, very likely! What did you do with the PIC so that this happened? Actually PICs are very robust chips. E.g. if you would clamp the RC output to ground or +5V, nothing dangerous would happen... So, something else has caused this defect! Best Regards, Thorsten.

In order to get 32 dim levels, you've to: 1) change the NUM_MATRIX_DIM_LEVELS to 32 in mbng_matrix.c: 2) change the rgb type in mbng_event.h from: typedef union { u16 ALL; struct { u16 r:4; u16 g:4; u16 b:4; }; } mbng_event_rgb_t; to: typedef union { u16 ALL; struct { u16 r:5; u16 g:5; u16 b:5; }; } mbng_event_rgb_t; change some checks in mbng_file_c.c which complain about values >= 16 (search for rgb) 64 dim levels: possible in theory, but much more changes are required, because the mbng_event_rgb_t type is only a 16bit variable, which can't store 3*6 bits. If you don't plan to use a RGB LED, you could write: typedef union { u16 ALL; struct { u16 r:6; u16 g:6; u16 b:4; // not used... }; } mbng_event_rgb_t; otherwise you would have to change it to a 32bit type, and this would require a lot of changes in the memory management and compression related functions in mbng_event.c It would also increase the memory consumption for each event! In addition, you've to set MIOS32_SRIO_NUM_DOUT_PAGES to 64 in the mios32_config.h file, and you should reduce the number of SRIOs (e.g. to 16) to avoid flickering. Best Regards, Thorsten.

Thanks for posting the pictures, this makes it much easier to get an impression about possible problems! :) I think that the cable length between the first and the second MBHP_DIO_MATRIX module is too long, this could cause such effects. It shouldn't be longer than 10 cm Best Regards, Thorsten.

Could this be related to the same issue like here? -> Best Regards, Thorsten.

Still waiting for the PCB (hopefully it isn't stucked at german Zoll...) For the STM32F4 version you can expect a pool size of 64k! :) Best Regards, Thorsten.

Ok, now it's clear to me what is going wrong here: else set_active (id)Enc:1371 1 The parser doesn't read commands after an ELSE statement. On the other hand, it didn't complain about the command - and this caused the confusion at your side. Here a new version which prints an error message whenever a command is detected after ELSE or ENDIF -> http://www.ucapps.de/mios32/midibox_ng_v1_029_pre3.zip Best Regards, Thorsten.

Hm... but how to switch between the different behaviours? I guess that most people don't want to add "dump=1" to all EVENTs, so that it can only be an optional parser feature. Best Regards, Thorsten.

The LCD cable should be as short as possible, I wouldn't use lengths > 30 cm Sending to an iPad/phone via OSC sounds like a good plan! It shouldn't be so difficult to integrate this into MIDIO128. But I'm unsure about a suitable application to display the text (at least OSC doesn't prevent you from sending strings) Best Regards, Thorsten.

Yes, the allowed voltage range is +/- 18V Best Regards, Thorsten.

It will take some time at my side until I will be ready to jump on the train, but I already found a very interesting usecase for this board: -> concurrent emulation of 8 SIDs for MIDIbox SID (V2 and also V3?) :tongue: Best Regards, Thorsten.

Hi, which application are you using? And did you consider that the LD signal has a very short pulsewidth (ca. 1 uS)? Best Regards, Thorsten.

Kann es sein, dass Dir Reichelt faelschlicherweise einen Fader mit logarithmischer Kennkurve geschickt hat? Das wuerde das Problem erklaeren. Ueberpruefe das mal mit einem Ohmmeter. Gruss, Thorsten.

Rumors told me, that Fairlightiii want's to setup a new bulk order! :) Best Regards, Thorsten.

No problem, sometimes I prefer faders & pots as well, especially when parameters should be tweaked during a live session and each fader/pot has a dedicated assignment anyhow. Such a PG-300 clone is a really easy entry point into the MIDIbox universe ;-) No programming skills are required if MIDIbox NG is used, since it provides an (hopefully easy to learn) configuration format. I found a SysEx specification under http://www.vintagesynth.com/roland/sysex.php And based on that I created a .NGC file to demo the configuration for a few control elements: http://svnmios.midibox.org/filedetails.php?repname=svn.mios32&path=%2Ftrunk%2Fapps%2Fcontrollers%2Fmidibox_ng_v1%2Fcfg%2Ftemplates%2Fpg300.ngc You've to upload this file to the SD Card via the Filebrowser in MIOS Studio after the MIDIbox NG firmware has been installed. You can also edit this file in MIOS Studio later. It's incomplete (because it's only a demo), but as you can see, adding remaining parameters will be straightforward. Just copy&paste the event definitions and adapt them... If you need more guidance (and if the Manual doesn't give you the infos), just let me know and I will explain in more detail. For the MIDIbox NG you would need following modules: - MBHP_CORE_LPC17: http://www.ucapps.de/mbhp_core_lpc17.html - SD Card: http://www.ucapps.de/mbhp_sdcard.html - MBHP_AINSER64 for up to 64 pots & faders: http://www.ucapps.de/mbhp_ainser64.html - MBHP_DINX4 for up to 32 buttons: http://www.ucapps.de/mbhp_din.html - MBHP_DOUTX4 for up to 32 LEDs: http://www.ucapps.de/mbhp_dout.html Kits for these modules are available in SmashTV's shop: http://www.midibox-shop.com The MIDIbox NG firmware is located under http://www.ucapps.de/mios32_download.html and gets frequent updates - just follow the progress in this dedicated forum section: http://midibox.org/forums/forum/46-midibox-ng/ Best Regards, Thorsten.

Thanks Kristal for documenting your build! Than more reports from different people, than less troublesome for most others! :) Btw.: an alternative report from Orange_hand can be found here: Resp. here: http://www.sequencer.de/synthesizer/viewtopic.php?f=13&t=70858&start=75 Unfortunately in german - but it has many pictures! ;-) Best Regards, Thorsten.

I will try this out tomorrow. Best Regards, Thorsten.