TK.

Could you please try if this quick hack is working at your side: http://www.ucapps.de/tmp/midibox_fm_v1_1d_rc1.zip I added a new SysEx command, but have no time to test it completely (e.g. check if storing instrument 2..4, drumsets/ensembles is working) from the documentation: d) F0 00 00 7E 49 <device> 0A <type> F7 Stores back the current patch into EEPROM/BankStick Can be used if no Control Surface is available - parameters can be changed via CC or SysEx <device>: device number 00-7F <type>: 00: Stores patch of Voice #1 01: Stores patch of Voice #2 02: Stores patch of Voice #3 03: Stores patch of Voice #4 10: Stores drumset 70: Stores ensemble setup [/code] Best Regards, Thorsten.

Hi, all OPL3 registers + MBFM sound engine parameters are stored in RAM, they can be transfered into a BankStick by calling the MBFM_BANK_StoreP function, which is located in src/mbfm_bank.inc ;; -------------------------------------------------------------------------- ;; Stores a patch from RAM in EEPROM or BankStick ;; IN: Instrument Number in MBFM_CURRENT_INSTRUMENT ;; Patch Number in MBFM_PATCH ;; Bank Number in MBFM_BANK ;; -------------------------------------------------------------------------- MBFM_BANK_StoreP [/code] How would you like to trigger this function? - via a button directly connected to the PIC - via a button connected to a DIN pin - via a MIDI event - via SysEx Currently, this only works via the control surface function (you have to go into the Save menu). Usually I prefer this laborious approach, as it prevents unintended store operations on HW issues (e.g. no DIN connected and somebody forgot to mount MBHP_CORE:R9, or random CCs are received from an external MIDI device...) But so long you know what you are doing, and provided that your HW runs stable, nothing prevents you from adding a dedicated possibility to trigger the store function. Only question: how do you want to control the bank and patch number, how do you want to differ between the instruments, and how do you want to store drum and ensemble parameters (MBFM_BANK_StoreD and StoreE)? Best Regards, Thorsten.

Panel number #00000002 up&running! I built it within two evenings, and I must highlight, that it was really a pleasure. It's extremely robust, and in distance to my breadboard based solution, there is no trouble with sticking the buttons/LEDs through the frontpanel holes, as everything fits perfectly! Well constructed, Wilba! :) Best Regards, Thorsten.

Adding an external sync function will be easy. Adding the possibility to define the bar position at which the MIDI Start event should be sent will be difficult, as I don't know, at which page the value should be configurable - any (realistic) idea? Best Regards, Thorsten.

1/2 Channels??? You should see 5 MIDI IO Ports if J1/J2/J3 are connected to ground (default) If you only see a single MIDI IO Port regardless of the J1/J2/J3 selection, check that Pin #25 is properly connected to ground. If you are unsure, solder Pin #25, and #5/#6/#7 again Best Regards, Thorsten.

-------------------------------------------------------------------------- MidiTest Results -------------------------------------------------------------------------- ================ Info ==================================================== Date: 23 Nov 2008 Time: 23:42:26 AppVersion: 4.6.231 OS: Microsoft Windows XP Professional, Service Pack 2 (Build 2600) Processor(s): Intel(R) Core(TM)2 CPU 6600 @ 2.40GHz Speed: 2394 MHz Number: 2 API: MultiMedia Extensions (MME) Test type: Advanced Use timestamp: yes Errors: None ================ Tested Message Types ==================================== Note off: yes Note on: yes Key aftertouch: yes Controller: yes Program change: yes Channel aftertouch: yes Pitchbend: yes System exclusive: yes MIDI time code quarter frame: yes Song position pointer: yes Song select: yes Tune request: yes MIDI clock: yes MIDI tick: no Start: yes Continue: yes Stop: no Active sensing: yes System reset: yes System exclusive mixed with realtime messages: no ================ Ports =================================================== MIDI Output: MIDIbox SID (1) Description: midibox.org GM5 Provider: midibox.org DriverDate: 11-20-2008 DriverVersion: 1.0.6.0 MIDI Input: MIDIbox SID (1) Description: midibox.org GM5 Provider: midibox.org DriverDate: 11-20-2008 DriverVersion: 1.0.6.0 ================ Results Per Message ===================================== MESSAGES Snd Rcv Snd+Rcv Message TotalTime: 1505.28 ms 23994.51 ms 25499.79 ms Message MaximumTime: 0.25 ms 2.21 ms 2.26 ms Message MinimumTime: 0.03 ms 0.00 ms 0.03 ms Message AverageTime: 0.05 ms 0.77 ms 0.82 ms SysexTime: 19.44 ms 2640.01 ms 2659.45 ms SysexAverage: 0.00 ms 0.26 ms 0.27 ms < 1 ms: 31250 22455 21219 1 - 2 ms: 0 8732 9953 2 - 3 ms: 0 63 78 3 - 4 ms: 0 0 0 4 - 5 ms: 0 0 0 5 - 10 ms: 0 0 0 10 - 20 ms: 0 0 0 20 - 50 ms: 0 0 0 50 - 100 ms: 0 0 0 > 100 ms: 0 0 0 Message count: 31250 Sysex count: 160 Sysex size: 10000 Sysex passed: 10000 Message latency: 0.82 ms Total time: 75.497 sec Message jitter: 0.39 ms Message max deviation: 1.44 ms ================ Results Per Byte ======================================== BYTES Byte TotalTime: 9956.80 ms Byte MaximumTime: 1.46 ms Byte MinimumTime: 0.02 ms Byte AverageTime: 0.32 ms < 1 ms: 31223 1 - 2 ms: 27 2 - 3 ms: 0 3 - 4 ms: 0 4 - 5 ms: 0 5 - 10 ms: 0 10 - 20 ms: 0 20 - 50 ms: 0 50 - 100 ms: 0 > 100 ms: 0 Byte count: 79569 Byte latency: 0.32 ms Byte jitter: 0.15 ms Byte max deviation: 1.15 ms [/code]

It means, that CS1/2 of the core are connected to the left GLCD, and CS3/4 to the right GLCD If you would use a 240x64 display, you would have to connect all 4 CS lines to a single GLCD (because in fact such a GLCD consists of four KS0108 controllers) Best Regards, Thorsten.

Ploytec released the GM5 Windows driver for midibox.org as an early christmas present for you: http://www.ucapps.de/mbhp_usb_gm5.html (if you don't find it at this page, click the refresh button of your webbrowser) It helps to overcome many flaws of the Microsoft legacy driver - it's multi client capable (you can run MIOS Studio and your DAW/MIDI Programs in parallel), transfers large SysEx bulks correctly, has much less latency when events are sent over multiple ports, and allows you to name the IO ports. Have fun! :) Best Regards, Thorsten.

Cimo: but this is what I'm doing to ensure consistency in the detailed documentation! (and thats the reason why I normaly ommit to create additional docs) I'm asking for a better description, because as a programmer I'm blind - I don't know why this description which already exists in the setup_*.asm file causes such misunderstandings as you can see in the schematic enhancement created by indeep. From http://svnmios.midibox.org/filedetails.php?repname=svn.mios&path=%2Ftrunk%2Fapps%2Fsequencers%2Fmidibox_seq_v3%2Fsetup_mbseq_v3.asm ; ========================================================================== ; In this table all button functions are mapped to the DIN pins ; ; The function name can be found on the left, the shift register and pin ; number on the right side. ; ; SR/pin numbers: ; SR = 1 for the first DIN shift register ; SR = 2 for the second DIN shift register ; ... ; SR = 16 for the last DIN shift register ; ... ; SR = 17 for the first DIN shift register of optional "misc. button matrix" ; ... ; SR = 24 for the last DIN shift register of optional "misc. button matrix" ; ; Pin = 0 for the D0 input pin of the shift register ; Pin = 1 for the D1 input pin of the shift register ; ... ; Pin = 7 for the last input pin (D7) of the shift register ; ; Set the SR and pin number to 0 if a button function should not be used ; ; The table must end with DIN_ENTRY_EOT! ; ========================================================================== [/code] So - where is the error? Which detail is missing? Best Regards, Thorsten.

Everything answered in the lounge... since it's a section only for programmers, you have to be logged in to read it! http://www.midibox.org/forum/index.php/board,37.0.html Best Regards, Thorsten.

It's a nice idea to add the pin numbers directly to the schematic. But could you please do this on the original .ps files? Otherwise your changes will get lost whenever I'm adding updates by myself. Original location: http://svnmios.midibox.org/listing.php?repname=svn.mios&path=%2Ftrunk%2Fschematics%2Fmidibox_seq%2F The .ps files have to be edited with xcircuit - the program is available for windows/mac/linux Best Regards, Thorsten. P.S.: the pin numeration you are using is wrong, the correct one: 1.0 - 1.7 corresponds to first shift register, pin D0..D7 2.0 - 2.7 corresponds to second shift register, D0..D7 etc It seems that you counted Vs/Vd (Ground, +5V) as digital inputs I guess that it would be better to improve the descriptions in the setup_*.asm files? But how?

This isn't a MIDI or application issue, since the upload works stable. Unfortunately my MBFM resists at the bottom of my 19" stack, therefore I'm not able to quickly do some scope measurements on my MBHP_OPL3 module for comparison with your waveforms. All I can say for now: noise below 10 mV can be safely ignored! With a scope you could check the digital interface first. Use the midibox_fm application instead of testtone for such checks, as testtone configures OPL3 registers only once after startup - so no periodic repetition, hard to measure... Send some >>different<< MIDI notes, so that the frequency registers will be changed. Check with your scope: that D0..D7/A0..A1 are toggling depending on note number that WR is toggling mutiple times whenever a note is played that RS is permanently 1 (so far I remember...) - it's the low active reset line No detailed descriptions required from your side for further analysis - it's only interesting if you see the signals toggling... yes? Then you can safely assume that the core is perfectly working. Btw.: did you already search for older postings where OPL3 modules were debugged. I remember a case where somebody soldered the chips with wrong pin orientation - the pinning can be confusing when you compare schematic with PCB layout, as the SMT chips have to be soldered upside down (-> mirrored pinning) Best Regards, Thorsten.

You will find postings about the details and progress in the programmer's lounge, just one board above this one. STM32 is not a PIC, it's an ARM Cortex-M based 32bit microcontroller - much more horsepower, much more memory, much easier to program, perfect choice for programming beginners due to less limitations for almost the same price. Only disadvantage: it's a SMT device, therefore hard to solder. Maybe pre-assembled boards could be provided later, but currently you've to solder the chip by yourself. Best Regards, Thorsten.

Hi Nsunier, it would be a nice addition to the platform :) The permanent clock requirement is tough for an application, which is doing a bit more than just outputing graphic icons. It wouldn't be a problem so long a dedicated SPI port would be available for these displays, but this would lead to too many restrictions for the 8bit platform. Therefore I propose to evaluate following approach: connect CLK input to J10:PWM (PIC pin RC2), and configure this pin to output 1 MHz (the MBSID application contains a configuration example) Use any other free pin as data line. It has to be 1 so long no data is transfered. In order to send data, disable interrupts, synchronize to the rising clock egde by polling RC2 input register (wait for the rising edge), set the data line, wait for the next rising edge, etc... until all bits are sent. Thereafter switch back the data line to 1 and enable interrupts again. At 1 MHz, the CPU can execute up to 10 instructions (note that a branch/goto will cost 2 cycles!) - this should be sufficient, considered that the driver is written in assembly. Future compatibility with MBHP_CORE_STM32: I've proven, that this clock synchronisation method also works with STM32F103, see sid.c driver. At 72 MHz, there are enough cycles free so that assembly language isn't really required. Even 4 MHz should be achievable. Alternatively, we could use one of two available SPI ports of the MBHP_CORE_STM32 module (J9 or J16) for full background control w/o bitbanging. This would restrict some usecases (e.g. DOUT SRIO or I2S normaly connected to J9, SD Card normaly connected to J16), but would unload the CPU almost completely, so that LCD transfers can be handled from a background task w/o disabling interrupts. As most application won't require a SD Card, J16 is really predestinated for such jobs. I hope that this information wasn't too confusing... Best Regards, Thorsten.

I like your music as well - great! Note that the "Cosaquitos en Globo" album is available at iTunes! :) Best Regards, Thorsten.

Thank you! I guess, that sooner or later I will like this layout as well! ;) There is one detail I don't like that much: my name under the midibox label. It's not because of the "perfume touch" (which Wilba mentioned), but because since some years MIDIbox turns into a project, where many people are adding their contributions. Accordingly, MIDIbox shouldn't be directly associated with my name, but with the community. E.g., my name under the logo would leave the impression, that only I'm allowed to call an application "MIDIbox xxx" - but in distance to this, I would like to see, that everybody who respects the community would use this name for his developments. Best Regards, Thorsten.

Thank you! Best birthday mail I got today: From: orders@goldphoenixpcb.biz Subject: Job shipped THKL01 11.10 mbhp_core_stm32_v1.zip [/code] :) Best Regards, Thorsten.

Jurbo: thank you! :) Puddingbrumsel: I could add a MIDI clock output, but there is a high danger that it will jitter, as the events have to be sent from a low priority task, while the internal synth is running on a high priority task (which isn't allowed to send MIDI...) So, under such circumstances, would it really be useful, or wouldn't it be better to use an external master for synching all your MIDI devices from the same source? Best Regards, Thorsten.

Ok, so the MIDI channel has been changed correctly. You should see the new channel at the main page? Best Regards, Thorsten.

Twin-X: don't worry, a delay will be available (therefore I've already prepared a "Fx" page, see GP button layout of the virtual MBSEQ V4) Moroe: duplicating the MIDI Outs will be sufficient for this usecase. Each additional MIDI Out will require 2 inverters of a 74HC00 (used as a buffer), accordingly 2 74HC00 are required to duplicate the 4 outputs of the MBHP_IIC_MIDI modules. As stated above: it isn't so difficult to provide access to more MBHP_IIC_MIDI modules (in fact it's already prepared for 8, and it could be extended to up to 128) - but IMHO it isn't worth the money, as there are cheaper solutions w/o real loss of functionality. Best Regards, Thorsten.

I just have tested it - works fine. Your MBSID should respond with: F0 00 00 7E 4B 00 0F 01 F7 after the SysEx string has been sent Best Regards, Thorsten.

MBSID V1 or V2? Best Regards, Thorsten.

It should be possible to write a driver for DOG GLCDs, but I don't own such a display, accordingly I cannot support it Best Regards, Thorsten.

Ok, I fried many (4?) LCDs this way in the last (20?) years - there is no way to fix it; it has to be replaced. Best Regards, Thorsten.

Very strange! Check the LCD connections and core module solderings, something seems to be wrong here. Especially the missing pixel line shows, that this isn't a software or configuration issue, as the HD44780 protocol doesn't allow to access the pixels directly (only characters can be sent). It cannot be excluded, that you damaged the LCD due to a wrong connection - did you change anything during build-up? Best Regards, Thorsten.