TK.

f0 00 00 7e 46 it seems that you've uploaded the wrong firmware - this is the SysEx header of MBSID V1 which is not compatible to a PIC18F4685 The link to the latest MBSID V2 firmware is published here: It's important that a V2 firmware is flashed into all PICs, otherwise the CAN bus won't work. This combination could even cause a short on the CAN bus - this could be an explanation for the high temperature on the second PIC. Best Regards, Thorsten.

The next giant matrix controller with a lot of X :thumbsup: Created by Ander aka. ALEXander aka. Wackazong

Great that you got it working! :) SID Player: the problem is that it has to run a C64 emulation for playback, because a .sid file contains the original sound player routine that has to be processed by a virtual 6510. For compatibility reasons, this would require at least 64k RAM + the RAM for MIOS32, the SD Card routines, etc. So, no chance to do this with a STM32 so long you don't use an external RAM as storage. A better solution is to use a tool like "siddump" to write SID register values and delays between write accesses into a file. Your MIOS32 app could read this file from SD Card and process it. Some time ago I wrote a small perl converter script to process the siddump output, you could use it as a basis for your own converter. The script is available here: http://www.ucapps.de/howto_sid_wavetables_1.html Best Regards, Thorsten. P.S.: I gave you access to the programmer's lounge.

Welcome back, Doug! :) Best Regards, Thorsten.

Today I sent the first OSC based MIDI messages from my iPad :) Macintosh:osc_midi_proxy TK$ ./osc_midi_proxy 192.168.1.108 10000 10001 Connecting to 192.168.1.108 on port 10000 Receiving on port 10001 in stat: : No such file or directory in stat: : No such file or directory [ 0] CoreMIDI, IAC Driver IAC-Bus 1 (default input) [ 1] CoreMIDI, IAC Driver IAC-Bus 2 (input) [ 2] CoreMIDI, Ploytec GM5 www.midibox.org Anschluss 1 (input) [ 3] CoreMIDI, Ploytec GM5 www.midibox.org Anschluss 2 (input) [ 4] CoreMIDI, Ploytec GM5 www.midibox.org Anschluss 3 (input) [ 5] CoreMIDI, Ploytec GM5 www.midibox.org Anschluss 4 (input) [ 6] CoreMIDI, Ploytec GM5 www.midibox.org Anschluss 5 (input) [ 7] CoreMIDI, Ploytec USB MIDI Junction II Anschluss 1 (input) [ 8] CoreMIDI, Ploytec USB MIDI Junction II Anschluss 2 (input) [ 9] CoreMIDI, Ploytec USB MIDI Junction II Anschluss 3 (input) [10] CoreMIDI, Ploytec USB MIDI Junction II Anschluss 4 (input) [11] CoreMIDI, Ploytec USB MIDI Junction II Anschluss 5 (input) Type input number: 0 [12] CoreMIDI: IAC Driver IAC-Bus 1 (default output) [13] CoreMIDI: IAC Driver IAC-Bus 2 (output) [14] CoreMIDI: Ploytec GM5 www.midibox.org Anschluss 1 (output) [15] CoreMIDI: Ploytec GM5 www.midibox.org Anschluss 2 (output) [16] CoreMIDI: Ploytec GM5 www.midibox.org Anschluss 3 (output) [17] CoreMIDI: Ploytec GM5 www.midibox.org Anschluss 4 (output) [18] CoreMIDI: Ploytec GM5 www.midibox.org Anschluss 5 (output) [19] CoreMIDI: Ploytec USB MIDI Junction II Anschluss 1 (output) [20] CoreMIDI: Ploytec USB MIDI Junction II Anschluss 2 (output) [21] CoreMIDI: Ploytec USB MIDI Junction II Anschluss 3 (output) [22] CoreMIDI: Ploytec USB MIDI Junction II Anschluss 4 (output) [23] CoreMIDI: Ploytec USB MIDI Junction II Anschluss 5 (output) Type output number: 13 HINT: next time you could select the MIDI In/Out port from command line with: ./osc_midi_proxy 192.168.1.108 10000 10001 --in 0 --out 13 MIDI IN 'CoreMIDI: IAC Driver IAC-Bus 1' opened. MIDI OUT 'CoreMIDI: IAC Driver IAC-Bus 2' opened. Proxy is running! ### Received 16 bytes [/midi1] timetag 0.1 (1 args), Method Arg: 0x00000000 [/midi1] 0: 643C9009 (MIDI) [MIDI_OUT] 90 3C 64 ### Received 16 bytes [/midi1] timetag 0.1 (1 args), Method Arg: 0x00000000 [/midi1] 0: 003C9009 (MIDI) [MIDI_OUT] 90 3C 00 ### Received 16 bytes [/midi1] timetag 0.1 (1 args), Method Arg: 0x00000000 [/midi1] 0: 643C9009 (MIDI) [MIDI_OUT] 90 3C 64 ### Received 16 bytes [/midi1] timetag 0.1 (1 args), Method Arg: 0x00000000 [/midi1] 0: 003C9009 (MIDI) [MIDI_OUT] 90 3C 00 ### Received 16 bytes [/midi1] timetag 0.1 (1 args), Method Arg: 0x00000000 [/midi1] 0: 643C9009 (MIDI) [MIDI_OUT] 90 3C 64 ### Received 16 bytes [/midi1] timetag 0.1 (1 args), Method Arg: 0x00000000 [/midi1] 0: 003C9009 (MIDI) [MIDI_OUT] 90 3C 00 ### Received 16 bytes [/midi1] timetag 0.1 (1 args), Method Arg: 0x00000000 [/midi1] 0: 643C9009 (MIDI) [MIDI_OUT] 90 3C 64 ... [/code] If you want to try this out: - update the repository - adapt the hard-coded IP address in Classes/OscServer_Wrapper.m (IP address of the host, will be configurable later) - compile and upload the application to your iPad - compile the OSC<->MIDI proxy under tools/osc_midi_proxy with "make -f Makefile.osx" - start it with "./osc_midi_proxy <ip-address-of-your-ipad> 10001" on your Mac and route OSC packets to a MIDI bus (or external MIDI interface) I haven't checked the performance (latency/jitter) yet, but will continue with this next week (after holidays...) Best Regards, Thorsten.

The virtual MIDIbox BLM16x16+X runs on a Windows PC or Mac and allows you to evaluate the new possibilities before building the hardware: Download and additional informations: http://www.ucapps.de/midibox_seq_manual_blm.html The thank-you goes to Phil Taylor, who ported the original Cocoa based solution to Juce, so that it can not only run on a Mac, but also under under Windows (and Linux if really required) Best Regards, Thorsten.

Duplicating LCD connections isn't possible, not at least because of the increased cable impedance (I tried this some time ago and noticed very bad results) I don't plan to add LCD output support to MBBLM because this would slow down the performance too much. Currently the performance is great, I don't want to make it bad by adding such minor features. Best Regards, Thorsten.

I will check this soon! Best Regards, Thorsten.

Thanks for the input! I changed the files in the repository Best Regards, Thorsten.

Hallo, Du bist der erste der danach fragt! ;) Fuer die baldige MIOS Studio 2.1 release koennte ich auch ein Linux binary bauen. Falls Du selber kompilieren moechtest, tippe mal "svn co svn://svnmios.midibox.org/mios32", gehe nach mios32/trunk/tools/mios_studio/build/linux", tippe "premake --file premake.lua --cc gcc --target gnu", anschliessend "make" (das MiosStudio.make file ist nicht mehr aktuell, deshalb muss via "premake" ein neues erstellt werden) Juce (v1.51) sollte sich im gleichen Pfad wie das heruntergeladene SVN Repository befinden, da auf die Juce Release mit indirekten Pfaden referenziert wird. Gruss, Thorsten.

E3 means that the SD Card wasn't mounted correctly. I've currently no explanation why this error could only occur while creating a new session, and why other file operations are still working. :-/ Do you have an alternative SD Card to try out if sessions can be created there? The reason for this "incompatible" behaviour is, that trigger layer assignments now also take effect on drum tracks. As you can read in the history of this thread, people were confused that this didn't happen before - I already feared that the result could be new confusion. ;) However, there is a simple solution: press MENU+TRIGGERS and assign "Gate" to trigger layer A, assign "Accent" to trigger layer B (if available), and disable the layers ("-") for all other trigger functions. Would it be sufficient to keep the last setting regardless of the track selection? Because I fear new error reports such as "strange behaviour of Octave/Semitone selection when switching between tracks". There is no other page that would behave this way So, you mean a possibility to play notes directly with GP buttons like in the BLM16x16+X video, with optional "force-to-scale", but w/o velocity? How to enter this mode - special button combination (which one?) or with a dedicated button? Best Regards, Thorsten.

http://svnmios.midibox.org/listing.php?repname=svn.mios32&path=%2Ftrunk%2Fetc%2Finf%2F This .inf file is already on your harddisk (-> SVN repository) Best Regards, Thorsten.

Alright, a new release is available now: MIDIboxSEQ V4.0beta22 ~~~~~~~~~~~~~~~~~~~~~ o running status optimisation can now be optionally disabled in the MBSEQ_HW.V4 file for MIDI devices that don't fully comply to the MIDI specification. Search for "RS_OPTIMISATION" in the MBSEQ_HW.V4 templates for further informations. o chaselight issue for mono colour 4x16 BLM fixed o trigger assignment page now works as intended in drum mode o new MIDI Bus parameters now loaded correctly after session change o another fix for crash if preset name is longer than 7 characters [/code] grizz: I need to know the error number if this happens Hint for Windows7 users: currently we (Phil and me) are very sure that the Windows7 USB driver provided by Microsoft cannot handle SysEx messages correctly in MIOS Studio if MIOS32 is configured for more than one USB MIDI port, because we have a counter example where SysEx transfers are perfectly working under Win7 with an alternative USB MIDI Driver. But I found a workaround that helps to get SysEx running again: open MIOS Studio, select the MIDI I/O ports of your MBSEQ V4 and type "help" into the MIOS Terminal multiple times until the complete help page is displayed: This allows you to upload a new firmware via USB w/o manually selecting bootloader mode. Btw.: virtual BLM16x16+X under windows anyone? :) Best Regards, Thorsten.

yes ok... I added the set/get functions, please update your SVN repository. -> http://www.midibox.org/mios32/manual/group___m_i_o_s32___u_a_r_t.html#g27e0f0a4efaf73173c9225e3e28d559a Best Regards, Thorsten.

Hi, Here: http://svnmios.midibox.org/filedetails.php?repname=svn.mios32&path=%2Ftrunk%2Fdoc%2Fmios32%2FMIOS32_CONFIG.txt The USB COM protocol only supports a single IO connection. Are you working under Windows? In this case you won't be able to run USB MIDI and USB COM in parallel anyhow (e.g. WinXP will crash!) - this would only work under MacOS Is this a hypothetical question, or do you really need this function? Then I could add MIOS32_COM_BaudrateSet() for you... Best Regards, Thorsten.

No - don't panic! ;) Yes, and once the MBSEQ_C.V4 file will be written again, these parameters will be replaced by MIDI_BUS_Channel 0 1 MIDI_BUS_Port 0 0 MIDI_BUS_Lower 0 0 MIDI_BUS_Upper 0 127 MIDI_BUS_Options 0 0x00 MIDI_BUS_Channel 1 2 MIDI_BUS_Port 1 0 MIDI_BUS_Lower 1 0 MIDI_BUS_Upper 1 127 MIDI_BUS_Options 1 0x00 MIDI_BUS_Channel 2 3 MIDI_BUS_Port 2 0 MIDI_BUS_Lower 2 0 MIDI_BUS_Upper 2 127 MIDI_BUS_Options 2 0x00 MIDI_BUS_Channel 3 4 MIDI_BUS_Port 3 0 MIDI_BUS_Lower 3 0 MIDI_BUS_Upper 3 127 MIDI_BUS_Options 3 0x00 [/code] and the error messages will disappear. Best Regards, Thorsten.

Congratulations! :) Best Regards, Thorsten.

Since each track only supports a single length layer, you have to realize this on a different way: use one track for the stretched or (better) sustained note use another track for the short notes. Assign both tracks to the same MIDI port and channel. Best Regards, Thorsten.

Depending on the track configuration that you selected in the "event" page, either one or two trigger layers are available. The first trigger layer A should always be assigned to the gate (if not, the gate will be triggered on each step) The second trigger layer is free assignable. Thats what you noticed. If your selected track configuration only supports a single trigger layer, the remaining 7 assignments are ignored. So, what should I say to this "issue description"? ;) Long time ago somebody requested this feature - he still wanted to control the sequencer remotely while recording a track. If you don't like this feature, just disable it in your MBSEQ_HW.V4 file (set MIDI_REMOTE_KEY to 0) yes and yes. I will try to reproduce this... Best Regards, Thorsten.

Yes, because it's more useful for sustained and stretched notes. (if you haven't tried this yet, do it now - it results into great sound effects! :)) It would be annoying if the CC would only be sent when a new note is triggered by the gate - for such purposes it's usually better to use the velocity parameter, and to assign it to the sound destination on your synth. To your initial request: since each step can only store 128 values (0..127), there is no possibility to disable a CC without reducing the original value range. You could either set subsequent CCs to the same value, or you could use a dedicated CC track where the gate allows you to disable CC steps. Best Regards, Thorsten.

No, the MBHP_ETH module isn't supported yet, but it will be soon once I receive the PCBs from Seppoman :) Instead of disconnecting the serial IOs, you could also clamp the CS line to +3.3V as long as you won't find a notification in the ChangeLog Best Regards, Thorsten.

Do you own a multimeter? Could you please measure the voltages between ground and J19:SO, J19:SC, J19:RC1 and J19:RC2 when a) the MBSEQ firmware is running (so that output drivers are enabled) and b) the core is in bootloader mode (J27 stuffed during power-on) so that output drivers are not enabled This would help to understand if it makes sense to continue with HW checks, or if a special application is required for further analysis. Best Regards, Thorsten.

When asking such questions you should mention in which country you would like to buy the parts. I guess that a Reichelt order number won't help? ;) Best Regards, Thorsten.

Hi, strange... - which EEPROMs are you using exactly? And which MBSID firmware version - The latest (and greatest)? Does this also happen when all IIC EEPROMs ("BankSticks") are removed from the sockets? Thats fine, the bidirectional communication is working, even to the second PIC The device number is flashed into the PIC. It won't change if you put the PIC into another socket. The "change_id" application (available on the MIOS download page) can be used to assign a different ID if this helps, but I guess that it won't make a difference at the end. Best Regards, Thorsten.

You have to set the following two environment variables to the path of your mios/trunk directory. Example: export MIOS_PATH=~/svn/mios/trunk export MIOS_BIN_PATH=$MIOS_PATH/bin [/code] (~ is a shortcut to your /Users/<your-login> directory) The export commands can be executed in the same shell where you will execute "make". Alternatively you can enter the commands into your ~/.bash_profile file, so that they will be executed whenever a new terminal is opened. Best Regards, Thorsten.