TK.

"No change" is selected when the position shows "-:--" Best Regards, Thorsten.

Discussion about preset patterns will be continued here: Best Regards, Thorsten.

How about following implementation (I think that this is feasible without much programming effort): template tracks can be stored as separate files into a special directory (e.g. presets/*.V4T) parameters are stored in text format, so that they could also be edited from a computer they can be selected in the Track Event mode page as suggested they can also be stored from there (last item in list "Store new Template") while importing a template it will be possible to selected parameter groups which should be inherited (e.g. Name, Chn, Layer Config (e.g. to import a drum map only), Steps, All) By storing templates into files the number of patterns wouldn't be limited, and we could easily share the presets :) Any other ideas? I splitted the thread and moved this part into the MIDIbox SEQ section. Best Regards, Thorsten.

Thats no problem if you give me a list/some concrete ideas It was clear to me that sooner or later somebody will request to load predefined labels/maps from SD Card. But the reason why I don't store them in RAM is neither lack of programming skills, neither lack of time, but just because I want to reserve the remaining 4k RAM for more useful features. ;) There could be a way to transfer a .txt file from SD Card into flash memory later. Or alternatively: to provide different preset patterns stored in a special bank. Would the availability of preset patterns really slow down the editing process so much - would a text file entry complicate the editing process too much? What would people prefer? (I for myself would prefer to edit preset patterns directly from the MBSEQ CS instead of using a text editor) But so long nobody sends me ideas for labels/drum maps I'm not sure how much memory should be reserved for this. In addition, I will have to balance the memory usage with the required code size for future features. My proposal: write a new forum topic in the MBSEQ section with a list of your label/drum map ideas. Let other users add their own ideas. This should give me a good overview about the requirements, so that I can implement the appr. functions into the firmware quickly w/o the fear that I will have to change the programming concept again and again due to new requirements. Best Regards, Thorsten.

Such informations are mainly available in a hidden forum section for programmers only ;) However, some quick notes are located here StrydOne started a tutorial for Windows users here - it should still be valid with one exception: probably it isn't required to install MinGW and to copy the make.exe anymore, as somebody told me that MSYS now contains a working make.exe version. Btw.: could you please check this? It would really simplify the installation procedure: - install the precompiled GCC toolchain - install MSYS - set the MIOS32_* environment variables -> ready :) Could you please inform me about the additional labels that you are using later, so that I can integrate them into the official release? (there is enough memory free) Best Regards, Thorsten.

Thats a classical race condition - it's unpredictable which core will be ready for receiving MIDI events first (e.g. it depends on the code which is executed in the Init() function). Another issue: interrupts are not enabled during Init() - than longer it takes, than longer the core won't be able to receive MIDI events. Do you generate this "hello message" for debugging, or is it required for your application? In this case, there are much better methods which I could propose. MIOS specific SysEx events generated by the first core are filtered by the second core. They are not tunneled to avoid feedback loops. You could temporary turn your second core into a common MIDI merger (w/o endpoint enable) by using the Debug Tool which is integrated into MIOS Studio. It allows you to execute the MIOS_MIDI_MergerSet() function with WREG=1 (=MIDI merger enabled) for Device ID 01, so that MIOS specific messages of the first core are forwarded by the second core. See answers above - both are explainable and expected. Best Regards, Thorsten.

Thats normal under Win98SE, WinME and WinXP Great! :) Best Regards, Thorsten.

Thank you! :) And: POIDH! (the forum has such a nice gallery function now where we can archive user pics) Best Regards, Thorsten.

Hi Andy, it looks like a driver is installed on your PC which overwrites the original Microsoft Audio device driver. E.g., Nils noticed this with the "Logitech QuickCam" driver, and after he uninstalled it, USB MIDI was working again. You are always able to upload via regular MIDI. But you will really miss the fast USB speed (100x faster than MIDI) If you have the option, I strongly recomment you to use MacOS (*) - in distance to Windows, the USB MIDI driver implementation works perfectly without any limitations! :) And in distance to Linux, it is guaranteed that it will work without additional driver installation/troubleshooting/incompatibility issues. Best Regards, Thorsten. (*) note that MIOS Studio requires mmj or Mandolane to access the MIDI ports in Java.

A new version of MIOS Studio is now available for download. Changes: Enhanced MIDI Filter GUIGUI elements saved to XML filesAdded MRU lists for workspace configurations, MIDI filter definitions and hex filesLoading of .hex files into upload window now significantly faster (relevant for large MIOS32 projects)added SysEx Send/Receive window As always: thanks Adam for help! :) Best Regards, Thorsten.

Which MIDI interface are you using? I hope that it isn't listed here Best Regards, Thorsten.

Define an array which contains counter variables for each individual DOUT pin: // in this example for up to 16 pins #define NUM_DOUT_DELAY_CTR 16 unsigned char dout_delay_ctr[NUM_DOUT_DELAY_CTR]; [/code] initialize these counters in Init(): [code] void Init(void) __wparam { unsigned char i; for(i=0; i<NUM_DOUT_DELAY_CTR; ++i) dout_delay_ctr[i] = 0; // ...remaining init stuff... Add following code to SR_Service_Finish(): void SR_Service_Finish(void) __wparam { unsigned char i; for(i=0; i<NUM_DOUT_DELAY_CTR; ++i) if( dout_delay_ctr[i] && --dout_delay_ctr[i] == 0 ) { MIOS_DOUT_PinSet(i, 0); } } [/code] done! Whenever you set a pin, set "dout_delay_ctr[pin]" to a value between 1..255 This value defines the delay in mS after which the DOUT pin will be cleared again. Best Regards, Thorsten.

Shipped 2009-10-21: joeribl jbaldwinroberts Vitaly Shipped today: roman01 einwang flip nsunier Best Regards, Thorsten.

Hi, it should work again. Best Regards, Thorsten.

Beta10/11 is available. From the ChangeLog: o Tracks/Patterns/Songs can now be exported to a MIDI file. The appr. menu function is available under UTILITY->DISK->Export o a simple MIDI In/Out monitor page has been added. The page can be entered via MENU+MIDI->MIDI Monitor (GP 16 button). MIDI Clock and Active Sense events are filtered by default. The filter option can be changed by pressing SELECT in the MIDI Monitor page. o separated "pattern length" from "measure length" parameter in UTILITY->OPT menu. Pattern length is used for synchronized pattern changes, and measure length for the Synch-to-Measure function. The left encoder below the item allows to select 16 step wise, the right encoder and datawheel stepwise. o Paste/Clr behaviour option in UTILITY->OPT menu implemented now o HWCFG file option "BLM_BUTTONS_NO_UI" implemented now [/code] (Beta11 contains two bugfixes for Beta10 - thanks to Gridracer for testing!) Best Regards, Thorsten.

Since people still hesitate to publish their MIDIbox SID patches, I thought it makes sense to inspire you by starting a new bank with a dedicated topic, and to give you the chance to fill the empty patches until all 127 slots are full. How does it work: download the attached .syx file (packed in a .zip file), and upload it into an unsused bank of your MBSID with Rutger's Librarian. Listen to the already available patches, and start to vary them, or create completely new ones from scratch. You can either do this directly on the control surface (like me), or with the Editor. Store each variation into an empty patch slot, and document the changes in a table like shown below. Don't delete/change existing patches! Thereafter reply to this article, and attach your new .syx file (packed in a .zip file) to this thread. I will combine your patches with my own .syx file and post the complete one in the first article. Once we reached 127 patches, I will move the file into the Downloads section of this forum - thereafter we can start a new topic! :) Here the current table: Patches are labled "Arp 2" .. "Arp 128" The "Sound" column only describes the oscillator sound | Arp | Sound | Dir | Sort | Hold | Speed | GLen | Range | Sync | CAC | One | Easy | Comments +-----+---------------+-------+------+-------+------+-------+------+-----+-----+------+------+----------- | 002 | Simple Pulse | Up | * | - | 32 | 6 | 1 | * | o | o | * | | 003 | Simple Pulse | Down | * | - | 32 | 6 | 1 | * | o | o | * | | 004 | Simple Pulse | U&D | * | - | 32 | 6 | 1 | * | o | o | * | | 005 | Simple Pulse | Up | * | - | 32 | 6 | 3 | * | o | o | * | | 006 | Simple Pulse | Rnd | * | - | 32 | 6 | 3 | * | o | o | * | | 007 | 3OSC Detuned | Up | * | - | 32 | 6 | 3 | * | o | o | * | | 008 | 3OSC Detuned | Up | * | - | 32 | 16 | 3 | * | o | o | * | | 009 | 3OSC Detuned | Up | * | - | 32 | 32 | 3 | * | o | o | * | | 010 | 3OSC Synched | Up | * | - | 32 | 32 | 3 | * | o | o | * | | 011 | 3OSC Filtered | Up | * | - | 32 | 28 | 3 | * | o | o | * | | 012 | 3OSC Filtered | Up | * | - | 32 | 28 | 3 | * | o | o | * | CutOff sweeped via LFO1 | 013 | 3OSC Filtered | Up | * | - | 32 | 28 | 2 | * | o | o | * | ENV1 Depth modulated via WT1 | 014 | 3OSC Filtered | Up | * | - | 32 | WT2 | 2 | * | o | o | * | + GateLen modulated via WT2 | 015 | 3OSC HP Fil. | Up | * | - | 32 | WT2 | 2 | * | o | o | * | + GateLen modulated via WT2 | 014 | 3OSC Filtered | Up | * | - | 32 | WT2 | 2 | * | o | o | * | + GateLen modulated via WT2 | 015 | 3OSC HP Filt. | Up | * | - | 32 | WT2 | 2 | * | o | o | * | + GateLen modulated via WT2 | 016 | 3OSC Detuned | Up | * | - | 32 | 32 | 3 | * | * | o | * | play multiple keys! | 017 | 3OSC Det. Saws| Up | * | - | 32 | 32 | 3 | * | * | o | * | play multiple keys! | 018 | 3OSC Det. Saws| Down | * | - | 32 | 32 | 3 | * | * | o | * | play multiple keys! | 019 | 3OSC Det. Saws| Rnd | * | - | 32 | 32 | 3 | * | * | o | * | play multiple keys! | 020 | 3OSC Det. Saws| Rnd | * | - | 32 | 32 | 8 | * | * | o | * | play multiple keys! | 021 | 3OSC Det. Saws| Rnd | * | - | 16 | 32 | 8 | * | * | o | * | play multiple keys! | 022 | 3OSC Det. Saws| Rnd | * | - | 46 | 32 | 4 | * | * | o | * | play multiple keys! | 023 | 3OSC Saw/LoTri| Rnd | * | - | Mixed | 32 | 4 | * | * | o | * | play multiple keys! | 024 | 3OSC Saw/LoTri| Rnd | * | - | Mixed | 32 | 4 | * | * | o | * | play multiple keys! | 025 | 3OSC Saw/LoTri| Mixed | * | - | Mixed | 32 | Mixed | * | * | o | * | play multiple keys! | 026 | 3OSC Saw/LoTri| Mixed | * | - | Mixed | 32 | Mixed | * | Mix | o | * | play multiple keys! | 027 | 3OSC TriOnly | Mixed | * | - | Mixed | 32 | Mixed | * | Mix | o | * | play multiple keys! [/code] Some words to the arp sounds: there are different ways to use the arpeggiator, I prefer to clock it with the BPM generator synchronized to an external MIDI clock. The Sync flag ensures, that notes are starting synchronized as well, e.g. with 16th notes if Speed is set to 32 I also enabled Easy play mode People who use the arpeggiator during improvisation to play "triller" notes or fast chords would disable the Sync flag, and probably also Easy Play mode. You are allowed to configure the arp(s) this way (of course) - but please document this in the table. Have fun! Best Regards, Thorsten. 127_arps__027.zip

I gave you access to the hidden programmers board, where you will find a lot of additional infos and discussions around MIOS32 and STM32... so far I remember, somebody also uses XCode for development (but if you are asking me: I still prefer typing "make" in the terminal) Informations about the toolchain installation can be found under trunk/doc/MEMO Best Regards, Thorsten.

This could be a feedback loop. In the BPM page, disable MIDI Clock In and Out for USB2, USB3 and USB4. In addition, disable MIDI Clock In for USB1, or select MIDI Clock Master Mode (instead of MIDI Clock Auto Mode). Or at Ableton Live side: ensure that MIDI clock is not sent to MBSEQ. Best Regards, Thorsten.

ChangeLog beta9: [tt] o If a sequence is already running, the MIDI file player doesn't cause a restart anymore. Instead in automatically synchs to the next 16 step based measure. o Track Event page: to trigger the Init function, GP16 has to be pressed for 2 seconds (a message will be displayed to inform about this) o fixed various minor bugs [/tt] Best Regards, Thorsten.

It should work now (beta9). In distance to the previous solution, the sequencer core is not disabled anymore in "Exclusive mode". Instead, the tracks will be muted (not visible in Mute page yet - will be done later) The MIDI file is now properly synchronized to the running sequence. This was really hard work at my side - I hope that all possible cases are covered! :-/ Yes, because there are 8 trigger layers, I had to find a way to make all layers selectable, so that no additional "Trigger Selection" button is required. Yes, so long more than 4 parameter layers are configured. I guess you configured it for 8 or 16? If a track only consists of 4 parameter layers, ParLayer C button will toggle between layer C and D cool! :) Yes, thats really too much!!! A MIDI file is just a stream of MIDI events, MBSEQ plays this stream to the end and optionally loops. Editing this stream would require a lot of work at my side which I don't really want to do. You could import the stream into one or more tracks, edit the events there, export back to a MIDI file and play it again... it's like rendering one or more patterns to a file, and play them as a single additional pattern in parallel to the 4 patterns which can be edited interactively. I will use Meta events to embed track parameters, so that they won't get lost during export/import. You could also export tracks/patterns/songs to a file, edit them with your DAW, and import back to MBSEQ. Currently I don't know, how comfortable this can be realized... due to all the options, the usage could get complicated. Adding even more features for the MIDI file feature would make the usage even more complicated. In short: I would like to keep it simple. thats possible now. Best Regards, Thorsten.

Hi, with MIOS V1.9g we got new encoder modes which mostly help to fix such issues. Details are currently only described in this article (german). Just try DETENTED3, DETENTED4 and DETENTED5 to check if one of these modes solves your problem. Best Regards, Thorsten.

Cheers! :) Yes, since MBSEQ can already play MIDI files, importing the data and doing the reverse thing is only a question of defining a good user interface, e.g. for track/range/resolution/event mode (note/CC or drum) selection It would be interesting if the MIDI file player works with all your .mid files - the parser has only been tested with my own files so far. Best Regards, Thorsten.

Your daily update... (ok, for tomorrow I haven't scheduled a new version ;)) ChangeLog of Beta8: [tt] o now your MIDIbox SEQ can play MIDI files, either exclusively or in parallel to the 16 sequencer tracks. MIDI files have to be copied into the /midi directory of your SD Card. To select a MIDI file, go to the UTIL->DISK->PLAY page, and select the desired modes (Exclusive/Parallel and Loop on/off) o MIDI file import and export prepared in UI, but not implemented yet! o MIDI port used to send a SysEx dump now selectable in file list browser o fixed various minor bugs [/tt] Have fun! :) Best Regards, Thorsten.

Thanks for the helpful input! So... Beta7 is available, this time with following features: [tt] o a new label editor allows to enter track and pattern names so fast and easy like typing a SMS on a mobile phone. Use the first 10 GP buttons or encoders to cycle the characters (like on a telephone keypad), and the remaining buttons/encoders to select a character directly, move the cursor, delete/insert characters, selecting a preset (with the encoder) and to exit the editor. This picture says it all - I really like the new entry mode - it's essential for fast filename entry of future features! :) o implemented synchronous pattern change after x steps (x=1..256) This function has to be enabled in the UTIL->OPT page. The same number of steps is used for the Synch-to-Measure function. o implemented Follow Song mode. It has to be enabled in UTIL->OPT menu. o a warning message will be print if Synch-to-Measure is enabled, and a track length greater than steps per measure is selected. o CC number selected in Track Event and LFO Configuration page now has to be confirmed with GP button below the appr. item. A warning message will pop up to notify about this unusual data entry method. In addition, the value will be marked with '!' so long it doesn't match with currently active value. o fixed various minor bugs [/tt] Best Regards, Thorsten.

Great! :) I will make this topic sticky - unfortunately Windows based applications are not released as "open source" (and I don't have tools to compile under Windows anyhow...), therefore this modification currently only exists for MacOS. Best Regards, Thorsten.