TK.

Since your uC as only 64k flash and 16k RAM, I can already inform you that the resources are not sufficient. Thats the current memory usage of MBLC (Logic Control == Mackie Control) Macintosh:midibox_lc_v2 TK$ make -s ------------------------------------------------------------------------------- Application successfully built for: Processor: STM32F103RE Family: STM32F10x Board: MBHP_CORE_STM32 LCD: ks0108 ------------------------------------------------------------------------------- text data bss dec hex filename 62400 96 14328 76824 12c18 project.elf [/code] text = flash bss = RAM ...and the application isn't completed yet Best Regards, Thorsten.

I don't like "bumpers" who think that they could make pressure for an answer this way, however here some notes that I can give you quickly. You have to copy the files under $MIOS32_PATH/mios32/STM32F10x to $MIOS32_PATH/mios32/STR7x and adapt each file (if possible), resp. leave them as empty wrappers if the appr. functionality isn't available. Peripheral drivers (if provided by STM) have to be installed under $MIOS32_PATH/drivers/STR7x Thereafter install the FreeRTOS low level layer to $MIOS32_PATH/FreeRTOS/Source/portable/GCC/STR7x The code under $MIOS32_PATH/programming_model/traditional requires adaptions as well. Port the $MIOS32_PATH/bootloader (especially the flash programming routines) Finally create a suitable linker file under $MIOS32_PATH/ld/STR7x - done! Best Regards, Thorsten.

If ipMIDI becomes a defacto standard, it shouldn't be a big problem to provide it as an alternative option. The protocol is simple but primitive compared to OSC. I guess that the transfer performance is almost identical. This is a controller which uses the Bonjour based protocol: http://futuremusic.com/blog/2010/03/23/midipad-announced-first-dedicated-wireless-midi-controller-for-apples-ipad/ According to the german introduction, no other iPhone/iPad application uses it yet, but the big advantage should be Plug&Play (no driver installation required) Best Regards, Thorsten.

Thanks, I will check this soon. Best Regards, Thorsten.

Guys, there is no real need to discuss about MIDI options via ethernet. As mentioned before, there seems to be a standard solution for the iPad provided by Apple. Alternatively, I've already developed a OSC->MIDI proxy which is really simple to use and which will very likely also run on the iPad. Here the MacOS and Linux version for example: http://svnmios.midibox.org/listing.php?repname=svn.mios32&path=%2Ftrunk%2Ftools%2Fosc_midi_proxy%2F A more general version (based on Juce) will be developed so that it also runs under Windows w/o adaptions. Main advantages: you can send other OSC messages to the same port (-> more flexibility) It will be compatible with the OSC option of MBSEQ And there is a separate HW based OSC->MIDI proxy: http://svnmios.midibox.org/listing.php?repname=svn.mios32&path=%2Ftrunk%2Fapps%2Fmisc%2Fusb_osc_midi_cv_proxy%2F Thats the most flexible solution, no? Best Regards, Thorsten.

Ok, so it's probably better to remove this file (remove the reference only!) from the compile list - in this case, the non-optimized libc printf() functions will be used. Best Regards, Thorsten.

Alright - this explains all your delay/latency issues. A MIDI port assigned to BLM_SCALAR shouldn't be used for normal MIDI output. The function is secret ;) Best Regards, Thorsten.

Hallo, mit einem RS232 maessigen MIDI Interface Ersatz wirst Du sehr wahrscheinlich nicht gluecklich. Vor 10 Jahren - zu Zeiten von Win95, Win98 und WinME - war das noch eine gangbare Loesung, doch seit WinXP/Vista/Win7 wird RS232 von M$ nur noch stiefmuetterlich behandelt, und die alten Treiber die man so im Netz findet laufen entweder gar nicht, sehr instabil oder lasten den PC zu sehr aus. Insofern kann ich die COM Option von MIOS nicht mehr weiterempfehlen - die macht nur Aerger! Ja, es ist moeglich MIOS und eine Applikation direkt in den PIC zu flashen, wenn man sich aus den verschiedenen .hex Files mit einem normalen Texteditor ein neues zusammenbastelt - doch im Endeffekt macht das nur wenig Sinn. Denn fuer einen MIDI Controller braucht man ja sowieso ein MIDI Interface, warum also nicht gleich den komfortablen (und uebrigens auch schnelleren) Weg zum Flashen der Firmware waehlen? Da Du einen PIC Programmer besitzt, koenntest Du Dir auch bei Reichelt einen PIC18F4550 kaufen (4.80 EUR) und die MBHP_USB_PIC Firmware flaschen (bzw. den Microchip USB Bootloader, und dann die Firmware via USB aufspielen) - so erhalest Du ein MIDI Interface, mit dem sich ein normaler "MIOS Core" programmieren laesst. Und die Loesung waere dann auch immer noch wesentlich guenstiger als die RS232 Loesungen im Netz! Alternativ (ich weiss ja nicht was Du mit dem Core Modul anfangen moechtest), koenntest Du Dir auch mal das MBHP_CORE_STM32 Modul anschauen - USB integriert, schneller gehts nicht, siehe auch diesen Vergleich: Gruss, Thorsten.

Yes, different page views for more comfortable parameter entry makes sense and they are easy to realize. I guess that at the end the "HW frontpanel" view will only exist for historical reasons ;) Memory leak: I will check this once I get my hands on the real device - otherwise debugging will be too time consuming. It's strange that printf() etc. are not working - the simplified version is implemented in printf-stdarg.c Best Regards, Thorsten.

It looks like you've assigned the BLM_SCALAR output port to IN1, can you confirm this? Go into the MIDI menu, select the Misc page, and check the port to which BLM_SCALAR has been assigned. Select "off" to disable it. Best Regards, Thorsten.

Very cool, thank you for the remote demonstration! :) I already feared that the GP knobs are too small, but I will try to improve the touch handling with tap and stretch gestures. As a workaround, you can already use the big datawheel to change the last selected value. By pressing the play button the sequencer should start - thereafter press the menu button, select "Info" and you should get a "stopwatch" value which tells you how long a sequencer update cycle takes. On the Core32 module it typically takes ca. 600 uS..1.5 mS (value depends on the amount of notes that are played in parallel) I noticed in the video, that the response of the buttons is sometimes too slow (resp. sometimes they don't switch) - probably the LCD emulation consumes too much time and therefore has to be optimized. Too bad that the UI doesn't provide priority task handling like FreeRTOS - this would simplify things a lot. Best Regards, Thorsten.

I don't see a relation between the SD Card and delays on MIDI Out. Are you able to record the MIDI Output into Nuendo with a MIDI interface connected to your PC? This would be a nice debugging help. Another interesting experiment: open MIOS Studio, select your MIDI interface as MIDI Input and play the notes. The timestamps in MIDI IN monitor will show you the delays very accurately in mS resolution. What delays do you see there (please post the log) Best Regards, Thorsten.

Ok, probably the blue color of the resistor confused you. No, thats fine and shouldn't cause any negative effect. Best Regards, Thorsten.

Hi Timo, The orientation of the diode is important and it's correct on this picture (and other pictures that are located on the MBHP_MF page) The orientation of the resistor doesn't matter. However, does this mean that you soldered the diode the wrong way? Thats very likely the reason why the voltage at C4 is so low, and why LM317 gets a short. Probably the circuit will work (no damages) if the diode pins are swapped. Best Regards, Thorsten.

Great that you solved this :) Best Regards, Thorsten.

Alright! This delay (the gap) is caused by the common MIDI baudrate - there is no way to prevent this, musicians are living with this effect since almost 30 years now ;) I guess that it is around 650 uS - can you confirm this by measuring this time with your waveform editor? Here a comparison which demonstrates the delay between USB MIDI (MBSEQ sends over USB1), running status optimized MIDI (MBSEQ sends over OUT1), and non-optimized MIDI output (not used by MBSEQ) The full article can be found here: MBSID issue: the track is clean (I'm able to load this pattern into my own MBSEQ) Therefore I've only two explanations for this effect: either a second track plays C-1 over the same MIDI channel, so that glide is triggered, or your MBSID patch has portamento permanently enabled. 1st assumption can be checked by playing G3T1 in solo mode 2nd assumption can be checked by playing the default patch of MBSID (located at A001 if you haven't overwritten it yet) Best Regards, Thorsten.

Hi Steve, 'sh' is not recognized as an internal or external command, operable program or batch file.[/code] Thats strange! It seems that the shell command cannot be found anymore (it's part of MSYS), although some previous "sh" commands worked w/o error. What happens if you type: [code] sh -c "echo test" And what happens with: sh ./bin/mios-sdcc -c -mpic16 -p18f452 --fommit-frame-pointer --optimize-goto --optimize-cmp --disable-warning 85 --obanksel=2 -I./src -I ./include/c -I ./include/share -DDEBUG_MODE=0 src/main.c -o _output/main.o in the command window? Best Regards, Thorsten.

Hi Jordan, for a 16x2 LCD the firmware has to be recompiled with "CS_MENU_DISPLAYED_ITEMS" set to 4 in the setup_* file that you are using. Best Regards, Thorsten.

The code to communicate with a BLM via MIDI is already integrated into the MBSEQ firmware and tested (with the virtual BLM). It won't be possible to connect a BLM16x16 directly to the MBHP_CORE_STM32 module which runs the MBSEQ firmware, therefore a second uC (a PIC) will be required. The BLM code which runs on a PIC has been started, but currently only supports 4x16 since I don't have a 16x16 HW ready yet to add and check the required changes. The project isn't documented yet, and it definitely needs some more work before somebody could start to build the project. Since I've already the required 256 buttons and Duo-Colour LEDs, I will build at least the basic HW on veroboards (nice relaxing work ;)). More informations (schematics, configuration options, etc.) sooner or later in a separate topic (not here!) Best Regards, Thorsten.

I'm not sure if the MIDI option is supported by Windows, but I've already implemented an OSC->MIDI proxy which should also work on a PC. Alternatively, use a MBHP_CORE_STM32 together with a MBHP_ETH module to run a MIDI (and CV!) proxy (the appr. MIOS32 application is already prepared, but not released yet) Or even better: run the MBSEQ V4 application on a MBHP_CORE_STM32 module and control it remotely from an iPad - this is probably the most efficient solution which guarantees best timings. :) But since you already built a control surface, using an iPad for a virtual BLM16x16 will probably be a better idea. There are many possibilities... ;) Did you power-cycle your MIDIbox? The MBSEQ_HW.V4 file will only be read during the boot phase. A short status message will pop up after boot which displays the loaded files, is HW marked with 1 or 0? Btw.: mixing DIN and DOUT modules is dangerous. If you ever notice flickering LEDs, create a separate branch for DIN and DOUT modules. Keep the cables so short as possible. If you don't notice this effect, there is no need to change the cabling. I'm not sure :-/ All SD Cards I own will be mounted correctly under WinXP Best Regards, Thorsten.

Hi, this issue is very likely not related to the resistor (and especially not to the tolerance value). To get a better understanding about the issue I need more input. Are the two notes played from a single track, or from two different tracks? Could you please post the track content? Just open MIOS Studio and type "track <track-number>" in the MIOS32 terminal. E.g., to get the informations of the first track, type "track 1" Are two notes played at the same time again like in the first example? Are the notes sent over the same MIDI channel? If not: check the step lengths (-> parameter layer C) - if the length value of C-1 is higher than 100% followed by C-2 on the next step, a slide will be triggered. If this doesn't help, please post the track content for this example as well. Best Regards, Thorsten.

Well, when I saw the first iPad videos my first idea was, that this is the ideal platform for a virtual BLM, not at least because of the multi touch capabilities which is the key for such kind of applications. I'm not sure if I still need a HW based BLM for myself anymore. The main advantage of the SW solution is the flexibility - you can quickly change the application to use the device for a different purpose, accordingly it saves some place on the desk. Beside of the virtual MBSEQ and BLM I'm also planning a flexible MIDI keyboard interface which changes its layout based on a selectable scale (only notes which are part of the scale can be played). Such a keyboard is impossible to realize in HW. ;) Another application will be a SysEx editor for MBSID - probably it will use the same code as MBSID V3 which will feature a touchpanel as well (but much smaller and w/o multitouch) So - these are already 4 useful applications that can run on the same device. :) I don't know a similar device in this price range with the appr. display size which supports multitouch Best Regards, Thorsten.

Do you remember if the latest bootloader release (v1.1) has been installed? (it's available under http://www.ucapps.de/mios32_download.html) With older versions the USB MIDI communication via Juce/MIOS Studio 2 will fail (at least under MacOS, I'm not sure if the same effect happens under Windows) Workaround: upload the new bootloader via UART based MIDI. As Phil mentioned, the J15:RW pin shout be connected to ground (thereafter power-cycle the core) to force bootloader mode. On the old core module, there was a resistor between J15A/B where this signal is available (see picture) Best Regards, Thorsten.

You can download the code from the command shell with "svn co svn://svnmios.midibox.org/mios32" The project file is located under trunk/apps/sequencers/midibox_seq_v4/ipad/MbSeq.xcodeproj It would be especially interesting if the virtual encoders are working properly. Note that MIDI output isn't implemented. I've heard that MIDI is provided via Bonjour, but haven't found documentation about this approach yet. Best Regards, Thorsten.