TK.

I added your request to the Wishlist (end of the CHANGELOG.txt sid_lfo_table.inc has to be enhanced (see end of this file) + the preset offset in sid_se_l.inc (search for "if LFO synched via clock, replace 245-255 by MIDI clock optimized incrementers") In addition the appr. CS code + Rutger's and Nils Editor have to be adapted. And the documentation has to be overworked of course. Best Regards, Thorsten.

MIDIbox FM V1.2 has been released! It supports the PIC18F4685 -> more memory, more features, more fun! :) You will get some nice looking waveform icons and an integrated random patch generator! :frantics: You can simply replace the PIC18F452 by a PIC18F4685 w/o changing the remaining hardware. Later the CAN interface for MBNET communications could be supported (but I'm still unsure if it's really worth the effort). As long as it isn't enabled, data to the MBHP_OPL3 module will be output to the complete J15 port by the setup_pic18f4685_mbfm_v1.hex variant so that there is no need for changing the connections. The setup_pic18f4685_sammich_fm.hex variant is already prepared for the MBNET option (again: it's unclear yet if it will be ever supported), D2 and D3 are output by the RE1 and RE2 pins, so that RB2 and RB3 pins are free for the CAN interface. The update is also relevant for PIC18F452 users: you will get the possibility to trigger notes from the CS, the Instrument LEDs will flicker on incoming notes, and there is a bugfix for finetune. From the ChangeLog: MIDIboxFM V1.2 ~~~~~~~~~~~~~~ o The firmware now supports the PIC18F4685. The additional memory is used for new features: - Nils added some nice looking special characters for LFO, OSC waveforms and operator connections - Wilba added some special CS handling code for sammichFM - TK added a random patch generator (-> RND page at the end of the menu) o Instrument LEDs are flashing now whenever a gate of an assigned oscillator is triggered o added possibility to play a note from the CS: press CFG + Instrument Key 1/2/3/4 to trigger a note o bugfix for finetune in upper range [/code] Have Fun! Best Regards, Thorsten.

#include <string.h> ... int bank = 0; memcpy((char *)current_prog_bank_name, (char *)prog_bank_list[bank].bank_name, 16); [/code] Best Regards, Thorsten.

The OPL3 is limited compared to DX7 (only 4 instead of 6 operators) and also FM8 (no additional Fx), but it's good enough for cheap GM sounds, and perfect for experimental sounds. :) Best Regards, Thorsten.

It's probably related to the slow SPI baudrate which has been selected in mios32_srio.h: // init SPI port for baudrate of ca. 2 uS period @ 72 MHz MIOS32_SPI_TransferModeInit(MIOS32_SRIO_SPI, MIOS32_SPI_MODE_CLK1_PHASE1, MIOS32_SPI_PRESCALER_128); [/code] what happens if you select MIOS32_SPI_PRESCALER_64, MIOS32_SPI_PRESCALER_32, MIOS32_SPI_PRESCALER_16, MIOS32_SPI_PRESCALER_8 (etc) instead. Change this in your local mios32_srio.c file for testing, start with higher numbers. It would be interesting at which prescaler value the LEDs get unstable. Best Regards, Thorsten.

Seems to be better sorted now, here the answers: 24 HC595 can't be driven in a chain - not for software, but for hardware reasons. You will find many articles in this forum where problems are discussed which you will face. Duggle nicely summarized it here: and gave a workaround, but it will be difficult to use if you don't have hardware experiences. In addition to this (hard to handle) hardware issue, you would also have to enhance the BLM_SCALAR driver because it's tailored around the BLM16x16+X MIDI Channels wouldn't be an issue for the limited capabilities of Ableton and Max4Live if you would implement a MIDI->OSC proxy by yourself... A comment to Note Events: they are normaly not used to control LEDs. Instead I'm using a very clever CC coding which allows to achieve high updates rates even over a common MIDI cable. With USB MIDI the update rate is incredible high (more than 1 kHz for all LEDs, although you would already be happy with 50 Hz...) Wrong. The README.txt for MIOS8 based version: http://svnmios.midibox.org/filedetails.php?repname=svn.mios&path=%2Ftrunk%2Fapps%2Fcontrollers%2Fblm_scalar%2FREADME.txt The README.txt for MIOS32 based version: http://svnmios.midibox.org/filedetails.php?repname=svn.mios32&path=%2Ftrunk%2Fapps%2Fcontrollers%2Fblm_scalar%2FREADME.txt Search for "optimized LED pattern" to find the CC based coding. For your project it might be sufficient to use two MBHP_CORE (8) based PICs with an unmodified BLM16x16+X firmware, and a GM5 for MIDI->USB MIDI conversion, an application running on a PC for USB MIDI->OSC conversion. Just to give you an alternative idea, because this solution doesn't require any firmware or hardware concept change. The update rate of the Core8 based solution is high enough (ca. 50 Hz) as you can see in the demo video. The adaption has to be done at PC level, this could be done by your friend w/ SW background. Note: you are already able to simulate the BLM16x16+X on a PC to evaluate the possibilities, and to write the MIDI->OSC adaption layer: http://www.ucapps.de/midibox_seq_manual_blm.html Best Regards, Thorsten.

Alright, we should add "ground connected?" to our default question. ;) MBSEQ counts octaves from -2, this complies to the Yamaha standard (I don't really like it, but there were too many unnecessary "bug" reports about the octave counting in the past) You are counting Octaves from 1, this makes the +3 difference Best Regards, Thorsten.

I won't reply to all your questions, because these are only unsorted thoughts and I find them too difficult to answer. I don't have the impression that you are ready for this project! Please read the already available README.txt for the current MIDI protocol. Think about the possibility to convert MIDI messages to another protocol with an application on your PC, because I'm saying that this is the best performance solution. If you don't believe me, go the route by yourself and make your experiences. Consider also that MIOS32 can open up to 8 USB MIDI ports in parallel as workaround for the WIndows driver which isn't multi client capable. Best Regards, Thorsten.

:thumbsup:

As far as I can see from your DWG file, you are trying to drive a column of 32 Duo-Colour LEDs from a single driver - this won't work! The current consumption is much too high. Using 8x8 matrices is the best choice HW and latency wise. From the SW side: it's possible, but you have to write a completely new BLM_SCALAR driver and BLM_SCALAR firmware, especially since you will need a new transfer protocol as well (even if you would use MIDI instead of OSC) You want to use OSC as transfer protocol, this will slow down the performance (see also my comments to OSC under http://www.ucapps.de/midibox_seq_manual_osc.html ) It's possible of course with some programming effort. But if you would ask me what is the best solution: use USB MIDI as transfer protocol, and convert MIDI messages to OSC packets on your PC (requires a proxy application) before forwarding the packets to Max MSP. My opinion shouldn't prevent you from making your own experiences with OSC of course - so to say it again: yes, it's possible. Best Regards, Thorsten.

Mokkinger will send me his AOUT_NG module for further analysis. It cannot be excluded that you've the same issue - please hold the line! ;) Best Regards, Thorsten.

ebay.de gives me 11 hits from different distributors in germany Price starts at 8.84 EUR Best Regards, Thorsten.

Probably the Pulsewidth is still set to 800 in your patch The pulsewidth has to start with a very low value (e.g. 010), and the envelope has to change it into the positive direction (which is the default behavior if you enable the ENV1->PW1 connection in the modulation matrix). This will sweep the pulsewidth from a very "thin" into the "crunchy" direction. Best Regards, Thorsten.

No, I haven't tried it yet because MBSEQ hasn't enough free memory for handling long filenames everywhere. And this could be your issue - e.g. avoid to declare variables of the large FATFS, but especially FIL structures as local variables (so that they are located in stack memory), instead declare them as global variables (e.g. "static FIL read_file_handle, write_file_handle;") After compilation you should be able to determine the actual variable size from the project.map file if for example read_file_handle is much larger than 500 bytes, you found the potential crash cause (stack is limited to 1024 bytes per thread) Best Regards, Thorsten.

Thanks for the compliments - now you should really contribute, regardless of the quality. Somebody else might fork a new patch from yours (-> double fun :)) Copy & Improve is explicitly allowed! Yes, it's only the feedbacked 6582 filter. Sometimes it sounds unusual since I'm driving it into saturation by using three oscillators for a single sound; the OSCs have to run at the same pitch (no detune!), the phases should be synchronized. This gives you some nice distortion for free :) Best Regards, Thorsten.

The error could also happen if you've uploaded the wrong MIOS version into your PIC. Please upload pic18f4685/midi/mios_v1_9g_pic18f4685.hex of the mios_v1_9g package, thereafter try to upload the application again. Best Regards, Thorsten.

Since you are using a single PSU, you should prefer starlike wiring: all grounds connected from the ground output of the PSU Best Regards, Thorsten.

Ich habe eine eigene Konfiguration erstellt (die dann auch in ein eigenes File erhaelt) Zum Einladen habe ich zwischen der Standard und der "MIDIbox" Konfiguration hin- und hergeschaltet, so hats bei mir geklappt. Gruss, Thorsten.

-> Best Regards, Thorsten.

Followup to Attached some bassline patches that I found on my second Bankstick. You already know the first ones from the remaining three ones were not published yet. Some short demos: direkt link, 13 MB (feedback pot used on all patches, external Fx and EQs have been added to the audio path) Update 2018-05-01: some new patches now released in SVN repository: http://svnmios.midibox.org/listing.php?repname=svn.mios&path=%2Ftrunk%2Fapps%2Fsynthesizers%2Fmidibox_sid_v2%2Fpresets%2F Some demos: http://www.ucapps.de/mp3/midibox_sid/mbsid_v2_tk2_soundbank_demo_part2.mp3 Please add your own patches to this thread, regardless if Lead, Bassline, Drum or Multi A MP3 which demonstrates the patches is nice to have, but no must! Best Regards, Thorsten. bassline_tk.zip

Use a pulse waveform and slowly modulate the Pulsewidth with an envelope. It's important that only a single oscillator is played, otherwise the sound will be "too fat" so that you won't notice the effect anymore. Best Regards, Thorsten.

For MIDIbox SID V2 you need a PIC18F4685 (96k flash). A PIC18F452 won't work, because it has only 32k flash. Also a PIC18F4620 won't work (this seems to be the first one that you tried) because it has only 64k flash Best Regards, Thorsten.

You should find the current consumption in the datasheet, it should be less than 10 mA. Best Regards, Thorsten.

Hi Mark, He bought a new AOUT_NG and this one worked for misterious reasons. If you are not able to solve the issue by yourself, would it be possible that you send me your module for further analysis? Because if this is a robustness issue, it would be good to know for me. Do you mean that your MBSEQ V4 is powered directly from the Mac w/o external supply, resp. an externally powered USB Hub? Yes, this could cause an unstable voltage with the effect that the AOUT_NG module won't work properly. Under certain conditions my own MBSEQ V4 crashes sporadically when it's directly powered from a Macbook Pro. Therefore I always use an USB Hub. Best Regards, Thorsten.