TK.

no, analog pots can only be used for the "assign" layer, there is no way to map them to other sections of the CS. The firmware already scans all 8 inputs, the the remaining 3 values are not forwarded to any parameter yet. I could forward them to the remaining 3 knob functions (which are normaly used for velocity/aftertouch and pitchbender), but I'm not sure if this is really what you want... Adding another mapping would be too time consuming work for me (not only the programming, but also finding a perfect solution which fits to future requests, enhancing documentation, answering future questions about this feature like this one...) Best Regards, Thorsten.

The adaption was successfull: it's possible to send data to SpeakJet w/o problems, and Audiocommander's application is running fine under MIOS32: http://svnmios.midibox.org/listing.php?repname=svn.mios32&path=%2Ftrunk%2Fapps%2Fsynthesizers%2Fmidibox_sj_v2%2F&rev=0&sc=0 More details about the (really simple!) circuit tomorrow. Best Regards, Thorsten.

sammichFM output connected to sammichSID input both MIDIboxes assigned to the same MIDI channel sammichSID: oscillators turned off, EXT on, stereo filter modulation perhaps it's worth a demo :w00t: Best Regards, Thorsten.

I would propose following SysEx checks on the GM5 module: 1) bridge J5:I1 to J5:O1 with a jumper or a small wire. This will create a loopback at TTL level Open MIOS Studio, select the first IN/OUT port - a feedback loop should be detected: http://www.ucapps.de/mios_studio/mios_studio_feedback.png Now test SysEx transfers by typing some arbitrary strings into the MIOS terminal input window as shown here: http://www.ucapps.de/mios_studio/mios_studio_feedback_sysex.png Does this work? Yes: 2) do the same test, but with a loopback via the MIDI IN/OUT socket (remove the jumper at J5) Does this work? Yes: 3) turn-off your MBSID and connect the MIDI cables. In MIOS Studio: select the .hex file and press the START button. You will get a notification that no response from the core has been received (of course, it isn't powered...) Now turn on your MBSID - the upload should be automatically started via 1st level bootloader. This method is a fallback solution which should always work, even if the application is crashing. Best Regards, Thorsten.

yes, no problem. I will post schematics which make possible (minimized) variants more clear once SpeakJet has been tested Best Regards, Thorsten.

Is there any of the 8 J5 input pins which isn't connected? -> it should be connected to ground (Vs) See also: http://www.ucapps.de/mbhp/auaimbctg.pdf Best Regards, Thorsten.

Finally I was able to reproduce the issue! :) Previously I used MBSEQ in drum mode (or a MIDI keyboard) to play the drums. MBSEQ plays the notes with 75% of the step length, with a MIDI keyboard the note length typically isn't shorter than 10..20 mS Today I used normal play mode instead, and came to the idea to vary the gatelength. It turned out, that drum triggeres were sporadically missing with minimum gatelength (where MIDI Note On/Off are sent back-to-back). So, the root cause is totally clear: in such a scenario MBFM set and cleared the gate before updating the OPL3 register -> no drum played. It was sporadically played if there was a small gap between Note On and Off command. However, I noticed that for OPL3 it doesn't matter how long the gate flags are set, the drum instrument is always played with the same envelope. Therefore I changed the handling from "gate" to "trigger" flags, and now it seems to work stable. Please try midibox_fm_v1_4c Best Regards, Thorsten.

sorry, no video... but: TK haz sammich :) Best Regards, Thorsten.

I would prefer standard MIDI to avoid DAW version dependencies (I've no Ableton Live installation anyhow and would have to install a demo version) Best Regards, Thorsten.

My base board is up&running, and I'm ready to test the "critical sequence". Could you please create a MIDI (.mid) file which causes the failures at your side, so that I'm able to reproduce this under the same conditions? Best Regards, Thorsten.

You don't need the complete board, just buy a LPCXPRESSO from Embedded Artists (for 20 EUR + shipping, delivery within two days), and solder it on a veroboard together with the SpeakJet, the 3.3V voltage regulator circuit and a USB socket (optionally also a MagJack and MIDI IN/OUT) See also http://www.ucapps.de/mbhp/mbhp_core_lpc17.pdf for a "full featured" board, but as mentioned: you don't need the whole circuit to get it running. :) yes, it will also run on a STM32 core thanks to the MIOS32 hardware abstraction layer :) But using the LPCXPRESSO is the best (and cheapest) solution. Best Regards, Thorsten.

You could use Rutger's Editor to assign the knobs w/o a control surface: Modulation Wheel is assigned to first AIN CC#16 is assigned to second AIN CC#17 is assigned to third AIN CC#18 is assigned to fourth AIN CC#19 is assigned to fitth AIN Best Regards, Thorsten.

Hi Chriss, interesting project, please keep us updated! :) I added following flags to the setup_*.asm file (code can be found in sid_se.inc) ;; filter flags supported by all engines #define DEFAULT_FILTER_LP_L_OUT 0 #define DEFAULT_FILTER_BP_L_OUT 0 #define DEFAULT_FILTER_HP_L_OUT 0 #define DEFAULT_FILTER_LP_R_OUT 0 #define DEFAULT_FILTER_BP_R_OUT 0 #define DEFAULT_FILTER_HP_R_OUT 0 #define DEFAULT_FILTER_O1_L_OUT 0 #define DEFAULT_FILTER_O2_L_OUT 0 #define DEFAULT_FILTER_O3_L_OUT 0 #define DEFAULT_FILTER_EXTIN_L_OUT 0 #define DEFAULT_FILTER_O1_R_OUT 0 #define DEFAULT_FILTER_O2_R_OUT 0 #define DEFAULT_FILTER_O3_R_OUT 0 #define DEFAULT_FILTER_EXTIN_R_OUT 0 ;; selected waveform supported by all engines #define DEFAULT_WAVE_O1_L_TRI 0 #define DEFAULT_WAVE_O1_L_SAW 0 #define DEFAULT_WAVE_O1_L_PULSE 0 #define DEFAULT_WAVE_O1_L_NOISE 0 #define DEFAULT_WAVE_O2_L_TRI 0 #define DEFAULT_WAVE_O2_L_SAW 0 #define DEFAULT_WAVE_O2_L_PULSE 0 #define DEFAULT_WAVE_O2_L_NOISE 0 #define DEFAULT_WAVE_O3_L_TRI 0 #define DEFAULT_WAVE_O3_L_SAW 0 #define DEFAULT_WAVE_O3_L_PULSE 0 #define DEFAULT_WAVE_O3_L_NOISE 0 #define DEFAULT_WAVE_O1_R_TRI 0 #define DEFAULT_WAVE_O1_R_SAW 0 #define DEFAULT_WAVE_O1_R_PULSE 0 #define DEFAULT_WAVE_O1_R_NOISE 0 #define DEFAULT_WAVE_O2_R_TRI 0 #define DEFAULT_WAVE_O2_R_SAW 0 #define DEFAULT_WAVE_O2_R_PULSE 0 #define DEFAULT_WAVE_O2_R_NOISE 0 #define DEFAULT_WAVE_O3_R_TRI 0 #define DEFAULT_WAVE_O3_R_SAW 0 #define DEFAULT_WAVE_O3_R_PULSE 0 #define DEFAULT_WAVE_O3_R_NOISE 0 [/code] Code changes are not released yet, but can be found in the repository: http://svnmios.midibox.org/listing.php?repname=svn.mios&path=%2Ftrunk%2Fapps%2Fsynthesizers%2Fmidibox_sid_v2%2F&rev=0&sc=0 Best Regards, Thorsten.

no, sid2midi only tries to extract notes (and note lengths + modulations), but it doesn't analyze the sounds. No, the ASID play mode itself doesn't process the content of a .sid file, it receives SID register changes from the host (running on your Mac/PC) and forwards them to the SID chips - nothing else. Best Regards, Thorsten.

dort trifft sich das elitaere gesocks ;-) Gruss, Thorsten.

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.