TK.

Yes, it has the same live recording mode. Yes! :) Best Regards, Thorsten.

No, it's held by a rail which is between the frontpanel and the PCB Difficult to describe for me, but I hope that this picture tells you more than 100 words: The frontpanel can be lifted by ca. 1..2 mm if you turn the case upside-down, but it can't be removed (and doesn't fall out) without opening the case because the PCB touches the rail. Best Regards, Thorsten.

Probiere mal den Upload ueber das SysEx Tool von MIOS Studio Gruss, Thorsten.

Ich vermute, dass die Applikation nicht abstuerzt, sondern reseted (neu startet), richtig? Hast Du evtl. vergessen, den Widerstand R12 am Core Modul zu verloeten, und/oder die Bruecke von diesem Widerstand nach Pin #28 zu ziehen? Siehe auch dieses Bild: Und diesen Schaltplan: http://www.ucapps.de/mbhp/mbhp_core_v3.pdf Gruss, Thorsten.

It isn't required to stick the frontpanel into the case the same way, as it sits flat at the top of the case. I remember that somebody wanted to try out a modified version, but I can't find the appr. posting and I don't know the result. Such a change could lead to the danger, that it will be more difficult to close the box if you are not able to lift the frontpanel anymore - but I could also be wrong. Best Regards, Thorsten.

Al works on the final PCB version, which will get some additional improvements such as an on-board VR and more trigger outputs. We consider to order another prototype before starting a bulk order. Yes: implemented, tested and working! :) Best Regards, Thorsten.

I decided this pinning more than 10 years ago - at this point of time the pinning was layout-driven, I don't wanted to cross signal lines. Of course, this can't be ensured for all encoder types... if it's an issue, you could either use a double layer PCB (which is probably the case anyhow?), or rotate the encoder by 180° I agree and I consider to change the default mode for all applications in future since most people use Reichelt encoders meanwhile (in distance to 2..3 years ago and earlier, where no encoders where available at Reichelt, and therefore most people used encoders from Voti - or the Burns Browns from SmashTV of course) I've some STEC11B encoders here, but need to test them by myself before providing the change. I'm also planning to take pictures of the connections to avoid such accidents that happened at your side. DETENTED2 increments/decrements at the rising edge of PinB, while DETENTED3 increments/decrements at the falling edge of PinB Actually I think that it could improve results even more if increments are done at the rising edge of PinB, and decrements at the rising edge of PinA... or on the falling edge instead This can be coded into the DETENTED value (no change in the encoder driver required), but again I haven't found the time to test this yet. When I'm using the encoders of my MIDIboxes (as mentioned above: mostly from Voti or SmashTV), I don't notice any difference between DETENTED2 and DETENTED3, therefore I need to setup a test configuration with ALPS STEC11B first Best Regards, Torsten.

If you've connected a LCD to your MIDIbox, you could upload the MIDImon application to determine the CC number. Without a LCD you could use a MIDI monitor running on your PC or Mac. E.g. for Mac I found this app useful: http://www.snoize.com/MIDIMonitor/ It has a very useful "spy" function which allows to display events sent to the MIDI Out. For PC you could use http://www.midiox.com in conjunction with MIDI Yoke: send the events from your DAW via a virtual (MIDI Yoke based) MIDI interface to MIDI-Ox to display the event. Best Regards, Thorsten.

The BankStick size will be detected automatically during formatting. It's very strange that they have been re-formatted after a firmware update, this shouldn't happen and may indicate a hardware failure (e.g. short circuit?) However, you could try following trick: upload the MIDIbox FM firmware, it will re-format the sticks for MBFM usage. Thereafter upload the MIDIbox SID V2 firmware: BankSticks will be re-formated again - this time for 64k? Best Regards, Thorsten.

Hi, see the frontpanel package provided by Wilba: http://www.midibox.org/dokuwiki/doku.php?id=wilba_mb_seq -> wilba_mbseq_fpd.zip I'm using the "wilba_mbseq_17in_opt.fpd" version + two wilba_mbseq_lcd_window.fpd Best Regards, Thorsten.

Cool, another fan of the Remix feature! :thumbsup: For a dedicated button you can assign the function to any free DIN pin in your MBSEQ_HW.V4 file, which should be stored in the root directory of the SD Card See the content of this file for further informations. Best Regards, Thorsten.

The change should work this way, but it should only be done once (for the case that this isn't obvious) in APP_ENC_NotifyChange before it's forwarded to the underlaying notification functions. Best Regards, Thorsten.

These are great news! I had a look into the programming examples, they are well structured. An adaption to MIOS32 should be possible without much effort. Feel free to announce the board here once it's available! :) Best Regards, Thorsten.

Such a function would have to be provided by the Host software - it also has to handle the blinking. MB64 doesn't know when you are loading a song... Best Regards, Thorsten.

Hi, in setup_midibox64.asm you could assign the menu buttons to different DIN pins which are not used, such as: ;; TK: menu buttons disabled for Benji #define DEFAULT_DIN_MENU_EXEC 64 ; would be the first button on the 9th SR #define DEFAULT_DIN_MENU_RIGHT 65 ; would be the second button on the 9th SR #define DEFAULT_DIN_MENU_LEFT 66 ; would be the third button on the 9th SR #define DEFAULT_DIN_MENU_SNAPSHOT 67 ; would be the fourth button on the 9th SR [/code] Thereafter the application has to be recompiled, and the new .hex file has to be uploaded. As you can see, I already did the changes for you... just download this special version (no new compilation required): http://www.ucapps.de/mios/midibox64_v2_4f_for_benji.zip Best Regards, Thorsten.

Hi, the .fpd file can be downloaded from: http://www.ucapps.de/midibox_seq/tk_mbseq_backpanel_v1_1.zip Best Regards, Thorsten.

I just have released a new version, it can be downloaded from http://www.ucapps.de/mbhp_mf_ng.html V1.002 got a Mackie HUI and Motormix emulation mode: For selecting the new modes you need MIOS Studio 2.2.4 (or higher) Best Regards, Thorsten.

Hi Eric, the hardware and the client API look promissing, but before buying a Copperduino board for evaluation purposes, I would like to know: 1) if the UART based interface of the CopperLan/Ethernet processor is directly accessible? This would allow me to connect it with a MBHP_CORE_LPC17 module without using the "application processor" as an unnecessary bridge. Background: the Arduino pinout isn't sufficient for most existing MIDIbox hardware, and porting MIOS32 to PIC32 would be a step back compared to LPC1769 and future, even more powerful processors. 2) are you planning to provide less costly boards without the application processor in future? I'm asking because costs and efforts for creating and selling an own board would be too high at our side. Best Regards, Thorsten.

Yes, MB64E has to be updated as well... soon - stay tuned! ;) Best Regards, Thorsten.

No - you can upload the .hex file directly to the core by using MIOS Studio. A .syx file conversion is neither required, nor supported for MIOS32 (since the approach via MIOS Studio is more robust) Best Regards, Thorsten.

Ok, now I've a better picture about what you are doing: you copied files from the $MIOS32_PATH/modules/uip_task_standard directory into your app directory and started to do modifications Mainly you replaced the copyright notice of the original creator by your own name which is btw. not a fair programming style! The Makefile enhancements of the uip_task_standard files are normally included with: # UIP Standard Task (with DHCPC + OSC server and client) include $(MIOS32_PATH)/modules/uip_task_standard/uip_task_standard.mk [/code] But for your own set of files, you've to add all "local" .c sources to the THUMB_SOURCE variable from your "local" Makefile - as you already noticed. Otherwise they will neither be compiled, nor linked into the project. Best Regards, Thorsten.

A jam session that I had together with Hawkeye (sitting in the background) in his studio: At 1:16, Peter added an impressive FPV recording made with his model airplane flying at the south border of "Starnberger See", a lake between Munich/Germany and the Alps. We started a bit uncoordinated, but found our style after 1..2 minutes. We hope that you enjoy the video anyhow! :ahappy: Best Regards, Thorsten.

Hi, for LPC17 you need a different, gcc based toolchain - it's very different from the PIC setup. I'm unsure if this works in Xcode, normally I execute the Makefile directly with the command shell. A link to the precompiled toolchain + additional informations can be found here: http://www.ucapps.de/mios32_c.html (follow the Mac Link) Best Regards, Thorsten.

I think that you are doing something wrong in the Makefile. Actually the sources should be automatically added when the *.mk file of the appr. code module is included from the Makefile as shown in the tutorials. Remote diagnosis is a bit difficult here, could you please type "make clean", zip the directory and attach it to this thread? Best Regards, Thorsten.

I will check this soon. Best Regards, Thorsten.