TK.

MIOS Studio 2.3.0 is available now Updates: MBHP_MF_NG tool: support for MIDI channel selection (requires firmware v1.3) added SysEx Librarian for MIDIbox SID V2 (requires firmware v2.41!!), MIDIbox FM V1 (requires firmware v1.4e!), MIDIbox 808 (requires firmware v1.3!!) and Waldorf Blofeld. I can add more synths (also unrelated to MIDIbox projects) on request if they support a simple way to exchange patches Screenshot of the new SysEx Librarian which is available under "Tools": IMPORTANT: for handling MIDIbox SID patches correctly, you need firmware version v2.041 or higher! for handling MIDIbox 808/Dr patches correctly, you need firmware version v1.3 or higher! Best Regards, Thorsten.

Thanks! :) There is some progress: patches can be moved around the bank. Insert/Delete is supported as well. Multi-Selections are possible there is now a "Transaction" and "Assembly" bank. The idea: the Assembly bank is a temporal storage which allows to compose a new bank from different .syx files or received dumps. Once it's ready, the Transaction bank can be completely cleared, the Assembly bank can be moved into the Transaction bank, and then stored into a new .syx file, and/or transfered to the MIDIbox patch names can be modified support for MBSID V2, MBFM V1, MB808 and Waldorf Blofeld (just for my own purposes ;-)) Best Regards, Thorsten.

ok for me Best Regards, Thorsten.

Zunaechst einmal wuerde ich die Motorspannung soweit reduzieren, dass der Fader schoen soft bewegt wird. 5V ist in der Regel ein guter Wert (beim alten MBHP_MF Modul war die Spannung noch etwas hoeher, das hat sich mit den neuen H Bridges geaendert) Ausserdem kannst Du in der Kalibrierungstabelle den minimalen und maximalen Wert einstellen. Per default stehen die auf 20/1000, wie schauts mit 40/980 aus? Gruss, Thorsten.

Hi, I'm already surprised that you were able to achieve this - there are no "control groups", the so called "radio button" function isn't supported by the MB64 firmware. It just doesn't support your usecase. You would have to program this into an own (e.g. C based) MIOS application. This isn't so difficult, there are various postings about this topic in the programming section. Best Regards, Thorsten.

A quick hack will be released soon: Background info: this Librarian was already on my agenda some months ago, but then I found Ctrlr and thought that it could make it obsolete. But the Ctrlr based "Program Manager" is far away from completion... Yesterday I spent some time to debug the panel restore issue in the current Ctrlr version (btw.: it's solved now, and meanwhile I would be able to release Ctrlr binaries by myself), by doing this I realized that if I would program a Librarian for MIOS Studio, I could later also integrate it into Ctrlr because both applications are based on Juce (I will ask Atom about this possibility once I've finished the MIOS Studio variant) So: the Librarian should be ready for use by end of this week - it will support MBSID V2 and MBFM V1, and maybe also some other MIDIbox apps. Best Regards, Thorsten.

Yes, various protocols are already supported. A list can be found at the end of this page: http://www.ucapps.de/midio128.html (still haven't found the time to create a generic description... most MIOS32 apps use the standard OSC client/server meanwhile) The protocol can be configured in the MIOS terminal (type 'help' for available commands) for port OSC1..OSC4 You could use the MIDI router (configurable in the terminal as well), to forward incoming and outgoing motorfader events from IN4->OSC1 and OSC1->OUT4 (assumed that your MBHP_MF_NG module is connected to J4B, for J5A connections use IN3/OUT3) Btw.: if you are working on a Mac, you could even transport SysEx messages via OSC by using the osc_midi_proxy: http://svnmios.midibox.org/listing.php?repname=svn.mios32&path=%2Ftrunk%2Ftools%2Fosc_midi_proxy%2F Best Regards, Thorsten.

I updated the firmware for the new BUFLCD driver (the complete repository has to be updated). You shouldn't really notice a difference - but in future it will be much easier to spread the message over more than 2 LCDs (e.g. 4 2x20 LCDs) To the MIDI channel situation (Apple wording): mm_hwcfg_midi_channel only sets the MIDI channel for buttons and encoders. For motorfaders you need an MBHP_MF_NG update which hasn't been released yet. @novski: is the preliminary MBHP_MF_NG release working at your side? Best Regards, Thorsten.

Alright, I fixed this - please update the repository. Later today I will overwork the LCD handling again, it's too cumbersome and error-prone as you noticed. Instead I will generalize the "buffered LCD" method which I implemented for MBSEQ. This method has also the advantage, that characters are only transfered to the LCD when they have been changed to increase the performance (especially important when GLCDs are used) OSC: the uip_task_standard module is already included. Once you know the OSC packets which are sent/received by the host, I can enhance the osc_server/osc_client accordingly. Best Regards, Thorsten.

How does it look like if the USE_TWO_LCDS option is disabled? And are you able to provide me the SysEx strings which have been sent by the host application to reproduce this? (e.g. if you are working under MacOS, use the snoize MIDI monitor with a "spy" MIDI Out) Best Regards, Thorsten.

should be ok now Best Regards, Thorsten.

Permission already granted, especially for such a nice build for such a fair price! :) Best Regards, Thorsten.

I can only say that some changes will be required to get this device properly working. I could help you on this (not immediately, but maybe in 2..3 weeks). Could you send me a board so that I'm able to try this by myself? Because remote-diagnosis is too time consuming. Maybe an important hint: check especially if all pull-up resistors are installed on the pins you are using - they are essential, because most pins are configured for open drain mode. Just compare with the MBHP_CORE_STM32 schematic Best Regards, Thorsten.

Hi, just update your svn repository, open mm_lcd.c and enable the USE_TWO_LCDS option in the header! :) Best Regards, Thorsten.

I can't compile for 10.5 since I've installed Xcode 4.4 on 10.8 Best Regards, Thorsten.

After building a MBHP_CORE_LPC17 module into my MBSEQ V3 I'm finally able to reproduce a hard-fault which has been reported. It happened when a preset pattern was exported - and was fortunately easy to fix. So, all MBHP_CORE_LPC17 users: please update to V4.062 MIDIboxSEQ V4.062 ~~~~~~~~~~~~~~~~~ o fixed potential hard fault when storing preset pattern [/code] Best Regards, Thorsten.

An inbuilt MIDI Arpeggiator is on the Agenda - it will feature the same functions like known from MBCV V2: http://www.ucapps.de/midibox_cv/v2_mockup/mbcv_mockup1_1.png Some extra buttons will be required to control the Arpeggiator, but I'm unsure how many are really necessary, and how many functions should only be controllable from the LCD based menu. Best Regards, Thorsten.

Stop: is this your intention? Then I would propose to build a MIDI Thru port instead of passing the MIDI clock events via software, because this would add a latency of ca. 300..500 uS Best Regards, Thorsten.

As already commented via PM: the MIDI connector pins are swapped in this layout. Best Regards, Thorsten.

Thanks! :) Ok, I will consider to create an alternative edit view for this. Best Regards, Thorsten.

Ok, understood - this could be added easily. Currently the live recording mode erases all nodes when you are holding keys - this is important for live recording to play keys for more than 1 step. I guess you are requesting the different behaviour for live recording in drum mode only, right? Here it could make sense (although I fear that it could confuse some people... but the functionality is useful) alright, fine! Best Regards, Thorsten.

This message indicates, that either invalid MIDI data is received via IN3 (located at J5B.A6), or that J5B.A6 is wrongly connected (if you don't use it: let it open - the internal pull-up should ensure to get a stable idle level) Best Regards, Thorsten.

fine! :) Best Regards, Thorsten.

The core module sends MIDI OUT at 3.3V level. 100% compliant MIDI devices are able to handle this, but older gear sometimes doesn't This also explains, why it works when the MIDI signal is routed through another devices. Normally MIDI Thru is buffered, and by doing this, it will probably be shifted to 5V which then works with your 909 As another workaround (if you don't like to sacrifice a MIDI Thru of another MIDI device), you could build a 5V level shifter by yourself. E.g. based on a 74HCT541 Best Regards, Thorsten.

Your ideas somehow don't match with the existing projects, therefore you probably have to program most of the functions by yourself - or you have to adjust your plans. Did you already read the tutorial? http://www.ucapps.de/mios32_c.html And the source code of the projects, such as: http://svnmios.midibox.org/listing.php?repname=svn.mios32&path=%2Ftrunk%2Fapps%2Fcontrollers%2Fmidibox_kb_v1%2F http://svnmios.midibox.org/listing.php?repname=svn.mios32&path=%2Ftrunk%2Fapps%2Fcontrollers%2Fmidio128_v3%2F Best Regards, Thorsten.