TK.

Ooof... I will give some feedback to your requests this weekend. ;) Best Regards, Thorsten.

Arrived also in the MIDIbox HQ today :) Best Regards, Thorsten.

Creating and documenting the case and the appr. firmware changes would be a very time consuming task, especially for somebody w/o assembly language skills. :-/ Best Regards, Thorsten.

There are generic IO configuration routines which are part of the low-level driver provided by STM. It's already part of the repository, used by MIOS32 and available for all applications as well. Here the source code if you are interested: http://svnmios.midibox.org/listing.php?repname=svn.mios32&path=%2Ftrunk%2Fdrivers%2FSTM32F10x%2Fv3.3.0%2FSTM32F10x_StdPeriph_Driver%2F (but again: the sources are already compiled into the application, no special treatments required to integrate them) Example to configure J19:RC1 (pin PC13) as push-pull output (0/3.3V): GPIO_InitTypeDef GPIO_InitStructure; GPIO_StructInit(&GPIO_InitStructure); GPIO_InitStructure.GPIO_Mode = GPIO_Mode_Out_PP; GPIO_InitStructure.GPIO_Speed = GPIO_Speed_2MHz; // weak driver to reduce transients GPIO_InitStructure.GPIO_Pin = GPIO_Pin_13; GPIO_Init(GPIOC, &GPIO_InitStructure); [/code] Example to configure J19:RC1 (pin PC13) as open drain output (0/5V if pull-up resistor is used): [code] GPIO_InitTypeDef GPIO_InitStructure; GPIO_StructInit(&GPIO_InitStructure); GPIO_InitStructure.GPIO_Mode = GPIO_Mode_Out_OD; GPIO_InitStructure.GPIO_Speed = GPIO_Speed_2MHz; // weak driver to reduce transients GPIO_InitStructure.GPIO_Pin = GPIO_Pin_13; GPIO_Init(GPIOC, &GPIO_InitStructure); Example to configure J19:RC1 (pin PC13) as input with internal pull-up to 3.3V enabled: GPIO_InitTypeDef GPIO_InitStructure; GPIO_StructInit(&GPIO_InitStructure); GPIO_InitStructure.GPIO_Mode = GPIO_Mode_IPU; GPIO_InitStructure.GPIO_Speed = GPIO_Speed_2MHz; // doesn't really matter for inputs GPIO_InitStructure.GPIO_Pin = GPIO_Pin_13; GPIO_Init(GPIOC, &GPIO_InitStructure); [/code] Example to configure J19:RC1 (pin PC13) as floating input (w/o pull device): [code] GPIO_InitTypeDef GPIO_InitStructure; GPIO_StructInit(&GPIO_InitStructure); GPIO_InitStructure.GPIO_Mode = GPIO_Mode_FLOATING; GPIO_InitStructure.GPIO_Speed = GPIO_Speed_2MHz; // doesn't really matter for inputs GPIO_InitStructure.GPIO_Pin = GPIO_Pin_13; GPIO_Init(GPIOC, &GPIO_InitStructure); MIOS32 configures J19 pins for software based SPI, but as long as you don't use MIOS32_SPI_...(2...) (SPI port 2), the pins can be used for other purposes w/o danger. Toggling pins: GPIOC->BSRR = GPIO_Pin_13; [/code] will set the pin to 1, and: [code] GPIOC->BRR = GPIO_Pin_13; will set the pin to 0 Best Regards, Thorsten.

If nothing unexpected happens, I will port ACs application to LPCXPRESSO this weekend. It will be fun and shouldn't take longer than 1 hour :) Since the LPC1769 already contains multiple UARTs, a MBHP_IIC_SpeakJet module won't be required anymore, instead the SpeakJet can be directly connected to the LPCXPRESSO And USB + OSC (Ethernet) will be supported "for free". :) Best Regards, Thorsten.

You could use the MIDIO128 application and check digital output states with a LED + 220 ohm resistor It's basically the same way like DINs can be checked, just the other direction: http://www.midibox.org/dokuwiki/doku.php?id=din_module Best Regards, Thorsten.

Hi Emre, SmashTV created a netlist + Eagle layout, just contact him, you could help with prototype testing if you are able to etch the PCB by yourself. Best Regards, Thorsten.

Creating and documenting the case and the appr. firmware changes would be a very time consuming task, especially for somebody w/o assembly language skills. :-/ Best Regards, Thorsten.

MIOS Studio 2.2.1 is available now Updates: fixed crash in MIDIO128 and MIDIbox CV Tool window pitch bend wheel working correctly now Best Regards, Thorsten.

SID players which provide the ASID protocol can playback most of the .sid files on a sammichSID via MIDI. See also and The controller was always running with the same configuration. I programmed the parameter assignments in the KNB menu of my MBSID instead, and stored them together with the patch, because this is much more flexible, and it especially shows me the parameter names instead of abstract numbers. Btw.: my Korg Microkontrol is damaged meanwhile, I can't really recommend to buy it. First every 8th key stopped working, by knowing that it must be related to the scan matrix I debugged this with a scope and found a bad solder joint on the PCB which was easily fixed. Some months later certain buttons stopped working, but I wasn't able to fix this anymore. :-( Also softwarewise it isn't so flexible as it could be. E.g., the LCD displays only show fixed (useless) names like Volume and Panorama... I already considered to replace the logic board by a core module, and to write an alternative firmware. ;-) Best Regards, Thorsten.

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.