TK.

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.

The brightness depends on R8-R16 - you could try if lower values help by adding a second 100 Ohm resistor in parallel (-> results into 50 Ohm) Btw.: for "cross-readers": such a low resistor value is only allowed if LEDs are driven time multiplexed from microcontroller pins which are limited to ca. 20 mA. Never use such a configuration when LEDs are directly connected to a PSU! I'm unsure if the buttons are still working with such a low value, your feedback is welcome! Best Regards, Thorsten.

Unfortunately I can't tell you the exact configuration steps, since I neither use the software, nor this hardware. I only remember that a german guy got this running with a Behringer Controller, but I can't find the posting anymore. It could either be in the german, or in the "MIDIbox of the Week" forum section. Somebody else did something similar: but he enhanced Tascam controllers instead of Behringers... the approach could be different. However, it should work this way: your DAW sends the display content to the virtual Mackie Control (BCFView) in a SysEx stream. The same stream has to be sent to the core module, the MBLC firmware decodes the SysEx data and updates the LCDs. There is no special configuration required to get this working, just upload the MBLC app, connect two 2x40 LCDs, forward the stream to the core module -> done Btw.: does the BCF2000 controller receive the complete Mackie Control stream directly, or does it get filtered/converted commands from BCFView? Best Regards, Thorsten.