TK.

Great! It's released now :) Best Regards, Thorsten.

I just have changed diskio.c, so that get_fattime is handled as a weak function now. Could you please check, if your function is now able to overload the "weak" implementation without source code change? Best Regards, Thorsten.

Cheers!

The green LED notifies that the module is correctly powered, and that the IIC_MIDI firmware is up & running. A Ground/5V connection is already sufficient for this state. Check the polarity of this LED (short leg: cathode) If you don't remember the length of the legs anymore, look into the LED: here the longer terminal is the cathode, the short one is anode. See also following photo: Best Regards, Thorsten.

You are using two timers which access the same resource, this leads to a conflict if both timers start a serial transfer back-to-back, because MIOS32_SPI_TransferBlock wouldn't queue the second request, but just overwrite the ongoing transfer (and I guess that this will lead to a hang-up) You would have to handle the queuing resp. scheduling by yourself from a single timer. Or better: since you are working with mS accuracy anyhow, I would propose to use a FreeRTOS thread instead, because they are typically much easier to program. E.g. a thread would allow you to wait until the transfer is finished, it would be interrupted by other higher priority threads in a mS timewindow so that your application doesn't get stucked. You could also add some semaphore handling later if required, this would allow you to access the same resource (e.g. the SPI port) from multiple threads without conflicts. Here is a complete example which might be very interesting for you: http://svnmios.midibox.org/filedetails.php?repname=svn.mios32&path=%2Ftrunk%2Fapps%2Fexamples%2Ffastscan_button_matrix_16x16%2Fapp.c because it determines velocity as well - for up to 128 keys (256 pins)! You have to add the appr. module to your Makefile: # For performance measurings include $(MIOS32_PATH)/modules/freertos_utils/freertos_utils.mk [/code] Best Regards, Thorsten.

It's better to change the debug port during runtime (e.g. in APP_Init()): MIOS32_MIDI_DebugPortSet(UART0); [/code] Best Regards, Thorsten.

Btw.: I will use a different set of spacers ("Distanzhülsen"): 7 x DA 5MM (at the top) 14 x DA 18 MM (two spacers sticked together, makes only 36 MM instead of 40 MM) no spacers for the core module Best Regards, Thorsten.

Well done! :) Best Regards, Thorsten.

The MSD mode works fine at my side, I'm using Lion as well. Sometimes you've to wait a bit until the device is available, because Spotlight scans all directories for new files. Best Regards, Thorsten.

Hi David, I remember that I had similar SysEx issues with my MIDIsport2x2 on a Mac back in January. They vanished after I used a GM5 based MIDI interface instead - haven't used the MIDIsport2x2 anymore... It was working very reliable under Win98 and WinXP years ago, but it seems that the Mac driver is buggy. MBFM SysEx transfers via MBSEQ: you have to assign a different device ID either to MBFM or MBSEQ. Best Regards, Thorsten.

You are right, since the source will probably never go into the original project (as planned), here the complete package: http://www.ucapps.de/tmp/sidplay4-source_4_1_4_asid.zip New files: ASID_MIDI.h ASID_MIDI.m PYMIDI (framework) Changed files: SPPlayerWindow.mm (instantiated ASID_MIDI) asid/libsidplay2/resid/resid.cpp (quick&dirty callback to ASID_MIDI) Best Regards, Thorsten.

I think that the STM32 based BLM + AIN modules are not a good combination. The multiplexed LEDs produce a lot of digital noise, and the analog inputs are only working in 0..3.3V range, accordingly the signal noise ratio is worse compared to 0..5V range used in PIC applications. I'm planning to provide a solution with cheap external 5V based ADCs soon (very soon), this will be interesting for you. Best Regards, Thorsten.

You don't need to solder these LEDs if you don't want to use the ethernet option. these are the contrast/backlight pots for LCD displays. You don't have LCDs connected (not supported by MBSEQ V4L anyhow), therefore you can ignore them. Best Regards, Thorsten.

Really great work! I like the assembly hacks, very inspirational! :) Best Regards, Thorsten.

It wasn't so easy to re-create all the required changes with the new Xcode GUI, but finally: -> http://www.ucapps.de/tmp/SIDPLAY_with_ASID.app.zip Btw.: I passed the source code to Andreas two years ago, but it's too difficult for him to test the integration, therefore we've to compile by ourself. Best Regards, Thorsten.

ordered! :) Best Regards, Thorsten.

It is possible to separate the BLM from MBSEQ with a plug, I'm doing this as well! :) See the socket at the right side of the rear panel: Here the schematic for the 8-pin connector: http://www.ucapps.de/midibox_blm/blm_connector_mbseq.pdf The BLM can be connected/disconnected during runtime and will be automatically detected, no need to reboot the sequencer. Best Regards, Thorsten.

I don't think that an IC is damaged... Did you build the BLM on a veroboard? First check should be to find out if only buttons or only LEDs are not working anymore. Buttons can be checked with a MIDI-Monitor: do they send MIDI events? LEDs can be checked with a MIDI keyboard (can also be a virtual one): send MIDI events to enable/disable the LEDs If LEDs and Buttons are not working, the common line connections (C_x, blue signals in my schematic) are the reason. You could swap two common lines to check if the connections on the BLM_SCALAR module are the reason, or the wiring on your Button/LED matrix Best Regards, Thorsten.

Nice! :) Under modules/fatfs/src/diskio.c you will find the get_fattime() function which is currently not implemented: DWORD get_fattime(void) { /* 31-25: Year(0-127 org.1980), 24-21: Month(1-12), 20-16: Day(1-31) */ /* 15-11: Hour(0-23), 10-5: Minute(0-59), 4-0: Second(0-29 *2) */ return 0; } [/code] I could declare it as "weak", this would allow you to implement an alternative version in your driver (a weak function will be replaced by your implementation if it's linked into the project) Best Regards, Thorsten.

Hi, Unfortunately this is hard to implement - resp. if I would change the sequencer engine to cover this request, it would have a disadvantage on MIDI timing accuracy (which I find more important than such a feature) Background: in distance to common MIDI sequencers running on a PC, the event handler of MBSEQ doesn't schedule MIDI events based on time, but based on the MIDI clock tempo. This results into a higher accuracy. This also allows to change the tempo during runtime without re-scheduling MIDI events (especially important for MIDI Echo Fx) As a side-effect, the granularity of the scheduler interval is independent from the time. It isn't possible to delay events with uS accuracy, only with "midi tick" accuracy, which depends on the tempo, and which is higher than 1 mS (e.g. at 120 BPM with 384 ppqn, it's ca. 1.302 mS, at 140 BPM it's ca. 1.116 mS) For a high accuracy and stable delay compensation, I recommend the usage of audio delays! Best Regards, Thorsten.

I wasn't able to reproduce this with Logic, but I noticed a missing feature: the divider wasn't cleared with a song position event. If Sonar doesn't send MIDI start, but a song position event instead, then this is the reason. Please try following version and give feedback: http://www.ucapps.de/mios/midibox_cv_v1_3.zip Best Regards, Thorsten.

Some additional J5 functions have been added to RC38, maybe they are enabled in your setup file, so that they overrule the initial gate settings. Could you please attach your setup file? Best Regards, Thorsten.

Thanks for the beautiful "Geburtstagsstaendchen" (serenade)! :) Best Regards, Thorsten,

I would like to give you some suggestions for improvements: - add feedback pots to your MB-6582 and enable the EXT filter function - this will result into a more aggressive bassline - switch to the Knobs layer in the oscillator section, so that the most important parameters CutOff/Resonance/EnvMod/Decay/Accent are directly accessible, you should change them more often - is it possible to route the audio output of MB-6582 through the Octatrack and to apply some effects? - (I only played an Octatrack once and therefore I'm unsure but..) is it possible to sample MB-6582 during a session for some beats and thereafter to apply effects on such a sample? Currently it sounds like two different instruments are playing in parallel, but somehow I miss the interaction between the instruments. Add at least a compressor (or limiter) at the end of the audio chain. Best Regards, Thorsten.

This seems to be a bug, but unfortunately I've currently no access to my hardware. Please up this thread in 2 weeks if I haven't replied yet. According to the source code the divider should be reset on an incoming MIDI start event: movlw 0xfa cpfseq IRQ_TMP1, ACCESS rgoto CV_CLK_NotifyRx_NoStart CV_CLK_NotifyRx_Start clrf CV_CLK_DIVIDER, BANKED ; clear clock divider (!) rgoto CV_CLK_NotifyRx_Start_Cont CV_CLK_NotifyRx_NoStart [/code] but it seems that this doesn't work correctly anymore. Or can anybody confirm that it works at his side? Best Regards, Thorsten.