TK.

There is no utility which would allow you to directly rip the sounds, but you could use siddump to get a trace of all register changes, and then setup your patch accordingly. I also wrote a perl script which simplifies the conversion, but it might be too difficult to use... See also: http://www.ucapps.de/howto_sid_wavetables_1.html (note: these tutorials are written for MBSID V1; wavetables have been enhanced in MBSID V2, and for drums it got a dedicated engine) Best Regards, Thorsten.

we will have a brainstorming session end of may :) Best Regards, Thorsten.

Even with MBNET enabled it works fine at my side, just listen to this mp3 http://www.ucapps.de/tmp/mbfm_drum_test.mp3 Of course, I also tried BD or HH only, with different patterns, etc... this was only the final stress test ;) I've no glue, I have to test this on the original hardware to search for the failure mode. Best Regards, Thorsten.

Don't worry, I proposed the PIC18F4685 because I knew that if necessary modifications would cause timing issues, the OPL3 register transfer routine could be optimized by putting it into a macro instead of a subroutine. This method would be possible thanks to the higher amount of available code memory, and it would save at least 6 cycles per register write. This would more than compensate the delay caused by PortE accesses. (I haven't tried it yet, and I haven't checked if emulating the delay would help to reproduce the issue - I prefer to test it on the real device, because it can't be excluded that the problem happens because of a programming error somewhere else :)) Are you able to reproduce the issue? Best Regards, Thorsten.

Yes, this is related to the dynamic voice allocation, as drum sounds have to share 6 oscillators, see also http://www.ucapps.de/midibox_sid_manual_d.html If a drum instrument is played very often (like bass drum), it could also be assigned to a dedicated oscillator. It's even possible to assign multiple instruments to the same oscillator, just for the case that they alternate anyhow (e.g. hi hats) (this also makes sense if a voice is routed through the filter) Yes, there are 16 instruments mapped to two octaves (=24 keys). The remaining 8 keys are not mapped (initially I wanted to avoid confusion...) Best Regards, Thorsten.

Yes - and the sound engines will run on the new core as well, so that higher update rates can be achieved, and coordination between the engines is easier (superpoly mode, synchronized sequences, 24-voice tracker :)) Best Regards, Thorsten.

...und dabei habe ich es so schoen im Tutorial erklaert ;-) -> http://svnmios.midibox.org/listing.php?repname=svn.mios32&path=%2Ftrunk%2Fapps%2Ftutorials%2F012_ain_muxed%2F Gruss, Thorsten.

Hallo Christoph, ja, das MBHP_CORE_LPC17 Modul ist noch nicht fertig layouted, und es wird sicherlich noch 1..2 Monate dauern, bis es allgemein verfuegbar ist (wir machen das ja in unserer Freizeit), doch ich wollte Dir zumindest schonmal die Info geben, bevor Du Dich spaeter ueber die verpasste Gelegenheit, mal etwas moderneres auszuprobieren, aergerst. ;) ja, der PIC ist ein etwas in die Jahre gekommener Mikrocontroller, mit dem man heutzutage noch nicht einmal eine Kaffeemaschine ansteuern wuerde. Mit einem LPC17xx dann schon eher (zumal ja heutzutage jedes moderne Haushaltsgeraet einen Internetanschluss verpasst bekommt ;)) Ja, die SMD Loetarbeiten entfallen, man loetet den LPCXPRESSO auf die Hauptplatine, doch das ist einfach und vor allem fuer Anfaenger ohne grosses Risiko. Grundsaetzlich ist es moeglich, mehrere LCDs anzusteuern, das wurde in MIOS32 so vorgesehen. Allerdings gebe ich folgendes zu bedenken: es gibt keine Character-Displays auf dem Markt, die fuenf Zeilen untereinander darstellen koennen. Man muesste also schon eher ein grosses Grafikdisplay mit einer hohen Aufloesung hernehmen, doch die sind exotisch (nicht einfach aufzutreiben) und/oder sehr teuer. Ausserdem muesste dann auch ein eigener Treiber geschrieben werden - so etwas koennte ich nicht blind machen, ohne das Display vor mir liegen zu haben. Doch viel groesser finde ich das Ergonomie-Problem: Display und Regler befinden sich zuweit auseinander, bei sovielen Werten wird es unuebersichtlich (und die Schrift wird sehr klein), so dass man letztendlich gar nicht mehr aufs Display schaut, sondern gleich auf den Monitor, auf dem die DAW vielleicht ebenfalls den Wert irgendwie darstellt. Es wuerde vielleicht mehr Sinn machen, die Bedienelemente und LCDs so aufzuteilen, dass sich moeglichst nicht mehr wie zwei Regler pro Reihe unter dem LCD befinden. So koenntest Du dann auch Standard 2x40 LCDs hernehmen, wie bspw. bei der MBSEQ V4 - die sind guenstig und haben einen vor allem einen leicht ablesbaren Schriftsatz. Bei EBay gibt es solche LCDs manchmal fuer 5 EUR, momentan leider nicht, nur diese hier fuer 11 EUR: http://cgi.ebay.de/BT24005-LCD-Modul-Display-Anzeige-2X40-LED-Backlight-/150585088360?pt=Bauteile&hash=item230f921968#ht_1438wt_907 Eine Spezifikation fuer die Moeglichkeiten zu schreiben wird sehr schwierig, da die Varianten extrem vielfaeltig sind. Wenn man den Controller-Ablauf selbst programmiert, stehen schon verdammt viele Moeglichkeiten offen (keine Panik, Deinen wuerde ich schnell selbst einhacken, der ist (noch) sehr simpel gestrickt und eignet sich gut als Programmierbeispiel) Programmiertechnisch kein Problem, doch unbedingt vorher die Dokumentation der verwendeten DAW checken! Fuer Logic reicht es bspw. aus, einen CC Controller mit 0 (fuer Aus) bzw. 127 (fuer Ein) zu senden. Gruss, Thorsten.

MIOS Studio 2.2 is available now Updates: LPC17xx code upload new tool for upcoming MBHP_MF_V3 support for Linux Best Regards, Thorsten.

Ich habe die Ursache gefunden und im Juce Forum gepostet: http://www.rawmaterialsoftware.com/viewtopic.php?f=5&t=6669#p39995 Werde dann morgen ein Binary fuer Linux releasen. :) Gruss, Thorsten.

Congratulations! :) If changing the wiring is too time consuming, I could give you a modified configuration where the 8 DIN pins of each shift register are mirrored Best Regards, Thorsten.

I remember that you asked me via PM, and I will send you the required informations for the update procedure soon. :) Important: don't try to downgrade to MIOS V1.8 anymore, this could damage the BSL installation, so that your PIC has to be reburned with a flash programmer! Best Regards, Thorsten.

Hallo, ich gebe Dir mal ein paar Vorabinformationen, da sie zu Deinem Projekt sehr gut passen. Die MB64E kann zwar bis zu 64 Encoder und 64 Potis gleichzeitig bedienen, wenn man die Konfigurationsfiles entsprechend anpasst, doch fuer Dein Projekt waere eigentlich eine MBHP_CORE_LPC17 basierende Loesung sehr viel besser geeignet. Dieser Core basiert auf einem ARM Controller von NXP, der mit 120 MHz getaktet wird, und USB, mehrere MIDI IN/OUTs und sogar Ethernet bereits integriert hat. Im Vergleich zum PIC ist er nicht wesentlich teurer, deshalb werde ich die PICs so langsam ausphasen. Damit man sich als DIY Neuling nicht mit SMD Loetereien herumschlagen muss, basiert das Modul auf ein "LPCXPRESSO" Evaluation Board, das es hier fuer 20 EUR + Steuer + Versand zu kaufen gibt (wenn Du alleine bestellst, ca. 40 EUR, bei einer Sammelbestellung ca. 30 EUR, Lieferung innerhalb von 2 Tagen!) Der LPCXPRESSO wird nun einfach auf die kommende MBHP_CORE_LPC17 Platine aufgesteckt, damit erhaelt man dann die MIDI/USB/Ethernet Buchsen, optional auch LCDs usw. Hier ein Bild vom Prototypen: Hinzu kommen dann auch noch anschluesse fuer die DIN/DOUT/AIN Module. Im Gegensatz zum MBHP_CORE_STM32 Modul werden die DIN/DOUT Ausgaenge gebuffert, so dass man auch mehr wie 4 Module hintereinander haengen kann. Das bedeutet, dass man fuer 90 Encoder problemlos 6 DINX4 Module hintereinander stecken koennte, so lassen sich bis zu 192 Eingaenge abtasten. Das Modul koennte dann auch ueber USB versorgt werden. Der Ethernet Anschluss haette in Deinem Fall einen ganz besonderen Vorteil: ich sehe auf Deinem Tisch ein iPad - viele Musikanwendungen kommunizieren ueber OSC, das auch von MIOS32 unterstuetzt wird. So koenntest Du das MBHP_CORE_LPC17 Modul nebenbei als "Proxy" verwenden, um bspw. OSC Daten, die von einer iPad Applikation generiert werden, in MIDI oder USB-MIDI umzuwandeln. Und umgekehrt (MIDI->OSC->iPad) Auch die Encoder und Dein MIDI-Keyboard koennten OSC Daten senden, bspw. an eine iPad Applikation oder wohin auch immer, macht also auf alle Faelle Sinn :) Zum Thema Pots oder Encoder: fuer Potis koennte man die "Soft-Takeover" bzw. "Snap" Funktion aktivieren, so dass solange keine Werte gesendet werden, bis das Poti die neue Position ueberschreitet. Doch damit das funktioniert, muss die DAW auch die Werte zum MIDI Kontroller senden, und das schafft leider nicht jede so konsistent wie man das gerne haetten. Insofern sind Encoder immer noch die geschicktere Loesung. Ein paar zusaetzliche Potis/Fader machen erfahrungsgemaess trotzdem Sinn, da sie sich "gefuehlvoller" bedienen lassen. Ich selbst verwende am liebsten Fader zur Echtzeitkontrolle von zugewiesenen (sinnvollen) Parametern waehrend des Spielens, und mehrfach gelayerte Encoder-Baenke zum Soundtuefteln. Kleiner Hinweis zu http://i53.tinypic.com/s5fsyv.jpg: da ist ein R zuviel, es heisst Arpeggiator Gruss, Thorsten.

Could you please upload the MIDIO128 application and check which MIDI notes are sent by each button and the encoder? Or are even multiple MIDI notes sent? Please list them here - this should help to locate the issue. See also http://www.midibox.org/dokuwiki/doku.php?id=din_module Best Regards, Thorsten.

I can't reproduce this issue, but for me it sounds like a firmware issue... It could be related to OPL3 register access modifications which have been made for sammichFM. Since they are slower than on the original MBFM design, and since interrupts are disabled while register values are transfered, incoming MIDI events could get lost. I'm unable to test this by myself, as I haven't got my sammichFM yet (seems to be stucked at german Zoll...) However, I added a "blind change" in the hope that it helps - MIDI interrupt isn't disabled anymore during register transfers. Could you please check this version: http://www.ucapps.de/mios/midibox_fm_v1_4b.zip Best Regards, Thorsten.

Hi, FreeRTOS controls the timesplices, it performs preemptive multitasking (see also this tutorial. However, using a timer is a better idea in this case, so you are already on the right route. Just for interest: why are you not using J16 with HW based SPI? another task could interrupt the task which generates the bitstream for J19, FreeRTOS guarantees that each task will be serviced in 1 mS On the other hand this means, that the bitstream generation will be slowed down... Again: using a timer is a good idea if HW based SPI at J16 can't be used. First idea: which SPI parameters are required for the slave? Clock Phase, clock polarity? There are four possibilities, and if you chose the wrong one, data transfer will be corrupted. In your current code, data is set with the falling clock edge, and data is read with the rising clock edge - does this comply with the datasheet of your SPI device? Best Regards, Thorsten.

The MBHP_CORE_LPC17 board will require this standard development board called LPCXPRESSO. So, in distance to MBHP_CORE_STM32 the chip + additional circuitry (like Ethernet PHY, small I2C EEPROM, crystals) won't be part of the board anymore. The kids would call it "shield" ;) This means also, that it will be possible to provide different variants for different purposes, or that somebody solders the additional components on a vero board like I did, e.g. to customize the interfaces/plugs for his case. Best Regards, Thorsten.

For those who prefer pictures: The LPCXPRESSO board is worldwide available for ca. 20 EUR + taxes: http://www.embeddedartists.com/products/lpcxpresso/lpc1769_xpr.php It's completely presoldered and tested. It will be put on top of the MBHP_CORE_LPC17 module which will provide the PSU and interfaces to the MIDIbox Hardware Platform. -> back to DIY friendly design! :) Best Regards, Thorsten.

Great that we sorted this out! :) of course, no problem ;) Best Regards, Thorsten.

Hi, yes, this can be achieved with following setup: ... [MIDI_IN] 1 = 90 30 2 = 91 30 3 = 92 30 4 = 93 30 ... [/code] This passes C-2 on Channel 1/2/3/4 to DOUT pin 1/2/3/4 Best Regards, Thorsten.

FPGA? Best Regards, Thorsten.

Hi, using DIN/DOUT modules for this purpose doesn't make sense! Scans wouldn't be fast enough anyhow ;) Direct routing of MIDI signals can be achieved with simple multiplexers, such as 74HC151. This chip routes one of 8 inputs to an output. 3 select lines allow to select the input Circuit for a 8x8 matrix (without support for input merging): - 8 MIDI INs with dedicated optocouplers - the circuit looks similar to the known MIDI IN stage of the core module - 8 74HC151, route the outputs of the MIDI IN stages to the inputs of these chips (each MIDI IN connected to each chip) - the 74HC151 outputs can be directly used for MIDI OUT, just add 220 Ohm resistors as known from the core module - the 8x3 select lines of the 74HC151 could be controlled from a MBHP_DOUTX4 module Best Regards, Thorsten.

Sounds like a pull-up isn't soldered correctly. Could you please doublecheck that R2 and especially R12 of the core module are properly soldered? Note that R12 is located under the PIC, and a bridge has to be added between J4 and this resistor (red cable in this snapshot: http://www.ucapps.de/mbhp/mbhp_core_v3.gif) Best Regards, Thorsten.

Yes, the network is correct, 221 means 22*10^1 = 220 Ohm Hm.... another possibility: could it be that the LED is connected to the wrong DOUT pin? How many LEDs are already connected? Only one? Do you know that DOUT Pin #0 is assigned to the leftmost output pin of the MBHP_DOUT_DINX4 module (J4:D7), and not to J4:D0? Best Regards, Thorsten.

The termination is (normaly) only required if multiple DIN/DOUT SRs are chained in mixed order like I did for MBSEQ (today I wouldn't do it this way anymore) It shouldn't be required if DIN and DOUT modules are connected in separate chains. Important: the cables should be as short as possible, between Core and the first DIN/DOUT module not longer than 30 cm! If this doesn't help, it's definitely related to the pull-up resistors. The 220 Ohm array has to be used! (neither 1k nor 10k) Best Regards, Thorsten.