TK.

Great progress - it seems that your version is becoming the best ASID player! :) Best Regards, Thorsten.

Thank you for publishing this great demo - I really like it! Do you allow me to add it to the MBSID main page? :) Best Regards, Thorsten.

Hi Robin, see this article: Best Regards, Thorsten.

If you want more room for additional button rows, we could ask Heidenreich for a second case design, e.g. for 4U or 5U panels. Best Regards, Thorsten.

Last update: I'm now using my own button elements, and the performance is much better. But it still doesn't run smooth on the iPad; it runs perfectly on the simulator (immediate update of the display). Since iPad and the Simulator (running on a MBP) communicate with MBSEQ via WiFi, I know that this is neither a MBSEQ issue, nor a protocol issue - it's either related to several Juce layers, or to the slow iPad CPU, or to the slow network interface of the iPad. For comparison: pinging an iPad from a MBP (MBP->WiFi->Router->WiFi->iPad): Macintosh:Desktop TK$ ping 192.168.1.110 PING 192.168.1.110 (192.168.1.110): 56 data bytes 64 bytes from 192.168.1.110: icmp_seq=0 ttl=64 time=26.624 ms 64 bytes from 192.168.1.110: icmp_seq=1 ttl=64 time=48.519 ms 64 bytes from 192.168.1.110: icmp_seq=2 ttl=64 time=72.720 ms 64 bytes from 192.168.1.110: icmp_seq=3 ttl=64 time=100.601 ms 64 bytes from 192.168.1.110: icmp_seq=4 ttl=64 time=143.209 ms 64 bytes from 192.168.1.110: icmp_seq=5 ttl=64 time=42.671 ms 64 bytes from 192.168.1.110: icmp_seq=6 ttl=64 time=84.293 ms 64 bytes from 192.168.1.110: icmp_seq=7 ttl=64 time=92.300 ms 64 bytes from 192.168.1.110: icmp_seq=8 ttl=64 time=112.074 ms 64 bytes from 192.168.1.110: icmp_seq=9 ttl=64 time=38.549 ms 64 bytes from 192.168.1.110: icmp_seq=10 ttl=64 time=63.361 ms 64 bytes from 192.168.1.110: icmp_seq=11 ttl=64 time=81.214 ms 64 bytes from 192.168.1.110: icmp_seq=12 ttl=64 time=105.147 ms ^C --- 192.168.1.110 ping statistics --- 13 packets transmitted, 13 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 26.624/77.791/143.209/32.190 ms [/code] pinging MBSEQ from a MBP (MBP->WiFi->Router->MBSEQ): [code] Macintosh:Desktop TK$ ping 192.168.1.112 PING 192.168.1.112 (192.168.1.112): 56 data bytes 64 bytes from 192.168.1.112: icmp_seq=0 ttl=64 time=6.479 ms 64 bytes from 192.168.1.112: icmp_seq=1 ttl=64 time=4.614 ms 64 bytes from 192.168.1.112: icmp_seq=2 ttl=64 time=4.037 ms 64 bytes from 192.168.1.112: icmp_seq=3 ttl=64 time=4.359 ms 64 bytes from 192.168.1.112: icmp_seq=4 ttl=64 time=4.237 ms 64 bytes from 192.168.1.112: icmp_seq=5 ttl=64 time=3.504 ms 64 bytes from 192.168.1.112: icmp_seq=6 ttl=64 time=3.329 ms 64 bytes from 192.168.1.112: icmp_seq=7 ttl=64 time=4.056 ms 64 bytes from 192.168.1.112: icmp_seq=8 ttl=64 time=6.043 ms 64 bytes from 192.168.1.112: icmp_seq=9 ttl=64 time=5.708 ms 64 bytes from 192.168.1.112: icmp_seq=10 ttl=64 time=3.650 ms 64 bytes from 192.168.1.112: icmp_seq=11 ttl=64 time=3.435 ms 64 bytes from 192.168.1.112: icmp_seq=12 ttl=64 time=4.524 ms 64 bytes from 192.168.1.112: icmp_seq=13 ttl=64 time=4.664 ms 64 bytes from 192.168.1.112: icmp_seq=14 ttl=64 time=5.734 ms 64 bytes from 192.168.1.112: icmp_seq=15 ttl=64 time=2.350 ms ^C --- 192.168.1.112 ping statistics --- 16 packets transmitted, 16 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 2.350/4.420/6.479/1.077 ms pinging MBSEQ which is directly connected to the ethernet port of a MBP (MBP->MBSEQ): Macintosh:Desktop TK$ ping 192.168.2.6 PING 192.168.2.6 (192.168.2.6): 56 data bytes 64 bytes from 192.168.2.6: icmp_seq=0 ttl=64 time=1.669 ms 64 bytes from 192.168.2.6: icmp_seq=1 ttl=64 time=1.506 ms 64 bytes from 192.168.2.6: icmp_seq=2 ttl=64 time=1.430 ms 64 bytes from 192.168.2.6: icmp_seq=3 ttl=64 time=1.177 ms 64 bytes from 192.168.2.6: icmp_seq=4 ttl=64 time=1.015 ms 64 bytes from 192.168.2.6: icmp_seq=5 ttl=64 time=1.010 ms 64 bytes from 192.168.2.6: icmp_seq=6 ttl=64 time=0.880 ms 64 bytes from 192.168.2.6: icmp_seq=7 ttl=64 time=0.706 ms 64 bytes from 192.168.2.6: icmp_seq=8 ttl=64 time=1.573 ms 64 bytes from 192.168.2.6: icmp_seq=9 ttl=64 time=1.396 ms 64 bytes from 192.168.2.6: icmp_seq=10 ttl=64 time=1.280 ms 64 bytes from 192.168.2.6: icmp_seq=11 ttl=64 time=1.181 ms 64 bytes from 192.168.2.6: icmp_seq=12 ttl=64 time=1.036 ms 64 bytes from 192.168.2.6: icmp_seq=13 ttl=64 time=0.914 ms 64 bytes from 192.168.2.6: icmp_seq=14 ttl=64 time=0.764 ms 64 bytes from 192.168.2.6: icmp_seq=15 ttl=64 time=1.634 ms 64 bytes from 192.168.2.6: icmp_seq=16 ttl=64 time=1.496 ms 64 bytes from 192.168.2.6: icmp_seq=17 ttl=64 time=1.286 ms ^C --- 192.168.2.6 ping statistics --- 18 packets transmitted, 18 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 0.706/1.220/1.669/0.293 ms [/code] Best Regards, Thorsten.

Update: communication via OSC is working, but graphic output is too slow. :-/ Time to optimize the "LED" handling. Best Regards, Thorsten.

Good news: the Juce based virtual BLM can be compiled for iOS It's properly running on my iPad - next step is to add the OSC code :) Imperfection: Juce isn't able (yet) to rotate the screen - seems that this has to be hardcoded. Best Regards, Thorsten.

IMHO connecting MIDI via a wire doesn't make on an iPad - computers have been invented for such a usecase, but not the iPad ;) You won't find so many informations about using OSC for MIDI, thats something that I've developed. I'm using the same library for MIOS32, Juce (-> MacOS, Windows, Linux), native MacOs and iPad - the code is optimized for embedded systems (and therefore runs much faster than common OSC libraries) and code written for this library is compatible with any of these operating systems. :) The problem is, that a complete new user interface has to be developed which is optimized for touch screen entry, because the "emulated frontpanel" isn't really ergonomic. I've no clear ideas about the UI part yet - it will need some months to work out such a plan, and here the process could be speed up if somebody experienced in creating user interfaces could help. Best Regards, Thorsten.

I guess that you are using Wilba's frontpanel? If SR6 toggles, it means that the last DIN SR has no pull-up at pin #10 (SER) Check that all resistor (arrays) are mounted and properly soldered! SD Card: please type "sdcard" into the MIOS terminal and copy&paste the output into this article. Note that by right-clicking on the terminal window you can copy the content (no need to make snapshots) MBSEQ supports FAT8, FAT16 and FAT32 And another hint: type "help" to get a list of some other helpful commands. Best Regards, Thorsten.

I've a similar project, but it's a little bit more advanced, because it supports: USB MIDI UART MIDI (up to 3 IN ports and 3 OUT ports) OSC (requires MBHP_ETH module) CV (requires MBHP_AOUT* module) Thats already possible by using OSC My plan is to provide such an app, but there are other higher-prio things in the queue... ;) We could speed up this if somebody would help me with the graphics! Btw.: OSC seems to be popular as well, e.g. Pianist Pro supports this: http://midibox.org/forums/index.php?app=gallery&module=images&section=viewimage&img=474 I'm able to directly control my MBSEQ with this app (w/o using a PC), and it's also possible to route key/pitch/CCs via the OSC port of MBSEQ to a physical MIDI IN/OUT by using MBSEQ Since this is working w/o problems, and since I'm already able to send/receive OSC messages on an iPad with my own applications, this is probably the route to go. Best Regards, Thorsten.

There isn't enough free memory in the PIC18F452 to add the code for the SID player. This was one of the reasons why I started with V2 on a new PIC Here the update instructions: http://www.ucapps.de/midibox_sid_manual_up.html Best Regards, Thorsten.

no problem for me, as Nils handles the orders ;) Best Regards, Thorsten.

First of all: you should update to beta27 to prevent this nasty crash issue! Thereafter: add the USB socket, because error messages are only sent USB1 (messages would affect the MIDI timings too much if they are sent over a common MIDI interface). Error 11 means that DOSFS wasn't able to create a new file. So this really seems to be an issue with your SD Card (either physically, or format related) The message sent over USB1 could give more diagnosis informations. Best Regards, Thorsten.

Hi, did you already consider to contact Akai support for a replacement? I had a similar issue on my Yamaha AN1x ribbon sensor some time ago - I called the local Yamaha service center in Germany and they sent me a replacement for only 10 EUR (including shipping!) :) Best Regards, Thorsten.

The blm_x driver can handle RGB LEDs: http://svnmios.midibox.org/listing.php?repname=svn.mios32&path=%2Ftrunk%2Fmodules%2Fblm_x%2F You could ask "this" for integration assistance. a DOGXL driver already exists under http://svnmios.midibox.org/listing.php?repname=svn.mios32&path=%2Ftrunk%2Fmodules%2Fapp_lcd%2Fuc1610%2F It has been created by Phil Taylor, and was also tested by Wilba However, with the 4x6 small_font only 40x13 characters could be displayed. You would need two displays (the driver supports this) Best Regards, Thorsten.

An extravagant demo! ;) Do you notice the same timing accuracy issues on a fast computer as well? My approach was to add a hook into the resid emulation, so that the emulated SID + the real SID can be played in parallel. This was the easiest way to compare the timings, but also the differences between original and emulation. Best Regards, Thorsten.

During a relaxing session with my BLM I noticed a crash scenario which was caused by a gcc compiler bug. This crash exists since beta26 (caused by several infrastructure updates), but it cannot be excluded that it already caused nasty random things in the past. Therefore an update is strongly recommended! ChangeLog beta27: o fixed a crash on rescheduled notes (caused by a gcc bug) o BLM keyboard mode: now inverted (lowest button row plays highest velocity) o BLM keyboard mode takes octave/semitones transpose values into account o copy/paste function: if Paste/Clr track is activated in options menu, channel and port setting will be copied as well. This allows to copy&paste a complete track from one pattern to another. o Paste/Clr steps/track setting in options menu is now a global setting and will be written into MBSEQ_GC.V4 instead of (the session specific) MBSEQ_C.V4 file. In future versions it might be a good idea to move global settings into a separate menu page. [/code] Best Regards, Thorsten.

Echopraxia: please try the new release, it displays messages in the MIOS terminal on SD Card errors. Beta26 is available now - from the ChangeLog: o SD Card error messages will be sent to MIOS terminal o added MIOS terminal commands "play" and "stop", so that the sequencer can also be started/stopped from MIOS Studio o the status LED of the core module flashes on each beat now o bugfix for FAST button o OSC support for "Pianist Pro" format (an iPhone/iPad application) Now you can send notes and pitch changes from Pianist Pro to your MBSEQ, and convert them into MIDI events o support for a third MIDI IN/OUT port. The digital MIDI OUT signal (open drain!) is available at J5B.A6 The digital MIDI IN signal is available at J5B.A7 Note that the MIDI IO circuit (220 Ohm Resistors, optocoupler, etc.) is not part of the MBHP_CORE_STM32 module and has to be added externally. This IO port can especially be used for a dedicated BLM connection (this will be my personal usecase) o Gate #7 and #8, which were previously available at J5B.A6 and J5B.A7, are now available at J5C.A10 and J5C.A11 [/code] References: new interconnection diagram which shows the "CV extension connector": http://www.ucapps.de/midibox_seq/mbseq_v4_interconnections.pdf schematic for MIDI IN3/MIDI OUT3 extension: http://www.ucapps.de/mbhp/mbhp_core_stm32_midi3_extension.pdf schematic for BLM connector: http://www.ucapps.de/midibox_blm/blm_connector_mbseq.pdf Best Regards, Thorsten.

Hi, I'm not sure if COM drivers are working properly with newer windows versions anymore. With WinXP users reported already issues... of course! :) MBSEQ V4 provides 4 MIDI USB ports, and they are working with best performance (much faster than common MIDI connections) Best Regards, Thorsten.

Attached you will find the pictures of a "certified circuit" ;) Ignore that I'm only using a 4-pin header, and ignore that +/- are swapped compared to the MBHP_CORE::J11 port Best Regards, Thorsten.

I'm just soldering my prototype BLM socket and noticed two things: some pins are swapped in your layout, and the footprint doesn't match with the socket available at Reichelt. More input soon. Best Regards, Thorsten.

From the documentation: The knob layer gives you access to 5 customizable parameters, which can be assigned to two different sound parameters, and which are also available as modulation sources. A Min/Max range can be specified for each knob individually. Assignments and ranges are stored within the patch structure - so, each patch can have its own set. This feature is intended for ergnomic usage during live playing, but also for easy MIDI automation (activate the CC function to send knob movements, so that they can be recorded with a sequencing software). Best Regards, Thorsten.

Finally I got a fitting backpanel from Schaeffer! :) No issues anymore - here is the .fpd file: http://www.ucapps.de/midibox_seq/tk_mbseq_backpanel_v1_1.zip Best Regards, Thorsten.

you are right, I mixed this with a question from another guy who wanted to multiplex more than 64 pots - in such a case the AIN multiplexers have to be controlled from remaining free pins, and if no AOUT or SID module is used, J19 would be a suitable candidate. But in your case it's ok to connect the multiplexer control lines to J15C as configured in this example: http://svnmios.midibox.org/filedetails.php?repname=svn.mios32&path=%2Ftrunk%2Fapps%2Ftutorials%2F012_ain_muxed%2Fmios32_config.h Yes, because the BLM_SCALAR has a DIN and DOUT chain as well. Just connect the DIN module to the end of the BLM DIN chain (J2, the upper pin row with RC/SC/SI/Vd/Vs) Best Regards, Thorsten.