TK.

No, MBFM and sammichFM share the same source code... Please try this firmware: http://www.ucapps.de/tmp/midibox_fm_v1_sd_experiment1.zip I added following flag to the setup_*.asm files which is enabled by default: ;; experimental option: HiHat parameters are changed when snare drum is played, since both instruments share the same operators #define DEFAULT_DRUM_SD_CHANGES_HH_OP 1 [/code] Try this especially when HH and SD are played in parallel - I would expect random results since this is a "race condition" (parameters are changed more or less concurrently) I also changed the labels in the FRQ menu to make clear which frequencies are changed. Best Regards, Thorsten.

thanks (again)! Will be fixed in the next version :) Best Regards, Thorsten.

fixed! :) Is anybody interested to join the prototype order? Estimated price: due to the low quantity ca. 10 EUR per PCB Best Regards, Thorsten.

The current approach is the best method to overcome the ADSR bug! You will notice this while playing the default multi patch, where sustain is set to a value > 0 which is normaly critical for an ADSR "hick-up" - with the implemented cycling it doesn't happen as long as notes are not played too quickly. Your requested mode would lead to unwanted side effects (ADSR bug would be initiated more often, or even randomly), therefore I think that it isn't worth to spend the time for implementing alternative methods. Another reason is, that such an option would be well hidden in a 3-character acronym, so that nobody would remember anymore what it means after some weeks. Best Regards, Thorsten.

It works with my STM32 core (where I've soldered the display cables directly on the PCB). I will desolder the display and check it with the LPC17 core later today. Best Regards, Thorsten.

It works with my STM32 core (where I've soldered the display cables directly on the PCB). I will desolder the display and check it with the LPC17 core later today. Best Regards, Thorsten.

It will be very difficult to get this working - sorry, the MBFM firmware was always overfeatured - with the latest bugfixes the usage of a PIC18F4685 is a must if special options like the AOUT interface should be enabled as well. Best Regards, Thorsten.

Hi, this is the relevant error message. Please set the MIOS_BIN_PATH variable, because it seems that it's empty You can do this with following command: export MIOS_BIN_PATH=$MIOS_PATH/bin [/code] Best Regards, Thorsten.

I haven't said "cable/channel" number, but cable number in byte 0, bit [7:4] of the Event Packet (see Figure 8) The MIDI channel number is coded into byte 1, bit [3:0] of the Event Packet. Please read the linked document again, it clearly explains the protocol, I couldn't explain it better. The second

Hi, Before I build up my old PC equipment in the cellar I would like to know, if this happens with the STM32 or LPC17 based core. Of course, this isn't normal. I checked this and found the reason (happens since a change in MIOS32 MIDI event handling) SysEx forwarding will work properly again with the next version! :) Best Regards, Thorsten.

Hi, since my PICstart programmer isn't compatible anymore, I can't try this out. So, I would be interested on the answer as well. The chip can be changed quickly, and the configuration only has to be done once (since the ID can only be overwritten by the special "change_id" app) It isn't really required to use such a special socket for this procedure. Best Regards, Thorsten.

The datasheet is wrong, Cymbal and Hi-Hat frequencies are not fixed. MBFM sets the Tom frequency (configurable in the FRQ page), whenever Tom *or* Cymbal is played. MBFM sets the HiHat frequency whenever the HH is played. MBFM doesn't set the HiHat frequency whenever Snare is played (in distance to the coupling between Tom and Cymbal) I don't remember if this was intentional or not, but this explains why you noticed the inconsistencies. It could be that I decided to handle drums this way because some own drum patterns sound better. But I could add a compile-option for changed handling if you want to do some experiments. Best Regards, Thorsten.

No, currently the only supported algorithm is "oldest note will be killed first" if there is no free voice anymore. Free voices will be cycled from 1..6 Best Regards, Thorsten.

Yes, every "USB MIDI cable" is handled like a separate MIDI interface, proven on MacOS 10.4 .. latest/Linux/WinXP/Vista/Win7 (at least) The DAW software only looks for MIDI interfaces, and every USB device which is compliant to the USB-MIDI specification (-> http://www.usb.org/developers/devclass_docs/midi10.pdf ) can announce up to 16 - just follow the descriptor example. Each interface has a cable number, which is coded in byte 0, bit [7:4] of the Event Packet (see Figure 8) Best Regards, Thorsten.

Logic Control was created by Mackie - they renamed the device to Mackie Control a few months before Emagic (the company which developed Logic Audio) was bought by Apple. This happened many years ago, therefore you won't find so many guys who know the history ;) Best Regards, Thorsten.

Your question isn't specific enough, I don't know what you want to achieve, therefore I fear that nobody can give you a sufficient answer... Of course, MIDI allows everything, the channel limitation can be easily bypassed by using SysEx messages. By transporting MIDI events via USB the speed doesn't matter, a clever MIDI implementation is even faster than any OSC solution (IMHO). While speaking about USB: with USB up to 16 IN/OUT "cable connections" can be created from a single USB port, which means 16x16 channels. This could be sufficient for your specific usecase if you are not able to change the DAW drivers? I mean (considering your last posting): you could create 16 virtual Mackie Control Emulations from a single USB MIDI device - is this for what you are searching for? Best Regards, Thorsten.

You haven't searched in the Wiki (keyword: "Mackie Control", first hit): -> http://www.midibox.org/dokuwiki/doku.php?id=midiboxlc&s[]=mackie&s[]=control Direct Link to the official MIDI Implementation: http://www.thomann.de/prodbilder/151261_manual.pdf Best Regards, Thorsten.

Alternatively MSD mode could be enabled via the MIOS Terminal. I've added a "msd on" command to all major applications meanwhile, see http://svnmios.midibox.org/filedetails.php?repname=svn.mios32&path=%2Ftrunk%2Fapps%2Fcontrollers%2Fmidio128_v3%2Fsrc%2Fterminal.c as an example (search for "msd") Best Regards, Thorsten.

You can't fix this, but I can do this for you ;-) The linker error was related to one of the last changes in mios32/LPC17xx/mios32_uart.c, which is fixed now. Please update the repository and compile again with the original MIOS32 tool chain (don't use the Code Sourcery package mentioned by Phil, because it will cause other problems - you have to use exactly the same version like me for a stable build!) Best Regards, Thorsten.

Willkommen! :) Leider wird sich in diesem Forum wahrscheinlich niemand mit dem APC20 auskennen, da wir unsere Controller selber bauen. Vielleicht koennen Dir die Leute vom sequencer.de Forum weiterhelfen. Gruss, Thorsten.

Fein! :) Gruss, Thorsten.

Unfortunately semaphores won't work, as the MSD driver handles SD Card accesses from an interrupt service routine. Semaphores can only be used for FreeRTOS tasks. I don't see a solution without overworking the USB and MSD driver. Best Regards, Thorsten.

The sequencer will already work without a connected SD Card. In this case, the firmware will hang for the first 5 seconds (to search for the SD Card), the LED will show an animated progress bar. Without a SD Card, Load/Store and the Copy/Paste/Undo function won't work. In addition, you can check the system status with various commands in MIOS Terminal - just type "help". Best Regards, Thorsten.

Fine! Seems that the frontpanel PCB construction needs some more documentation... :-/ Clock via MIDI IN: thats a known issue (since yesterday) and it will be fixed in the next version: I forgot to take over a notification mechanism which was only implemented for STM32 yet... Second MIDI OUT: should work, but it only sends MIDI Clock, it doesn't send the sequenced MIDI events (like the first MIDI OUT) Merry Christmas! :) Best Regards, Thorsten.

We have to differ between a SMD, and a through-hole based solution (especially if IC sockets are used). It's unlikely that the PCB can still be used if the SMD chips will ever be desoldered. ;) Best Regards, Thorsten.