TK.

This is finally the first open source release of MIOS. The source files are especially interesting for developers who want to get an insight about the tasks which are running in background (hidden for the application), and maybe (or hopefully?) for people who want to optimize or enhance existing functions. The most recent files of the project are hosted at https://sourceforge.net/projects/mios and available via CVS - the repository will contain bugfixes and improvements before a release has been done ChangeLog for MIOS V1.5: if MIOS_SRIO_TS_SensitivitySet is called with WREG == 0x00, the touch sensor Pin RD.4 (J14 of the core module) won't be driven by MIOS anymore and therefore is free for other purposes the AIN handler has been optimized to a two-step state machine with a sample frequency of 200 uS USER_MPROC_NotifyTimeout hang-up has been fixed the internal registers have been rearranged for a better overview. Applications shouldn't be affected from these changes Note: the custom LCD drivers under http://www.ucapps.de/mios_download.html have been updated, since there are some additional public variables available. Thanks to all beta testers! Have fun! Best Regards, Thorsten.

This is finally the first open source release of MIOS. The source files are especially interesting for developers who want to get an insight about the tasks which are running in background (hidden for the application), and maybe (or hopefully?) for people who want to optimize or enhance existing functions. The most recent files of the project are hosted at https://sourceforge.net/projects/mios and available via CVS - the repository will contain bugfixes and improvements before a release has been done ChangeLog for MIOS V1.5: if MIOS_SRIO_TS_SensitivitySet is called with WREG == 0x00, the touch sensor Pin RD.4 (J14 of the core module) won't be driven by MIOS anymore and therefore is free for other purposes the AIN handler has been optimized to a two-step state machine with a sample frequency of 200 uS USER_MPROC_NotifyTimeout hang-up has been fixed the internal registers have been rearranged for a better overview. Applications shouldn't be affected from these changes Note: the custom LCD drivers under http://www.ucapps.de/mios_download.html have been updated, since there are some additional public variables available. Thanks to all beta testers! Have fun! Best Regards, Thorsten.

Wahrscheinlich ist der parallele Treiber am einfachsten zu programmieren. Morgen veroeffentliche ich den Source Code zu MIOS, darin findest Du den CLCD Treiber, den Du als Vorlage hernehmen kannst. Viel muss nicht geaendert werden, lediglich das Polling --> vereinfacht! <-- sich! :) Sonderzeichen werden von diesem Display wohl nicht unterstuetzt, deshalb koennen die huebschen Bargraphs nicht angezeigt werden. Gruss, Thorsten.

Ok, gut versteckt steht es quasi zwischen den Zeilen: source file path exceeds 62 characters Die maximale Pfadlaenge, mit der MPLAB umgehen kann, betraegt 62 Zeichen. Einfach das Verzeichnis nach \mios oder so verschieben, und dann sollte es klappen Gruss, Thorsten.

Konntest Du das Projekt auch vor der Aenderung schon assemblieren (um das auszuprobieren, reicht es aus, in das main.asm bspw. an beliebiger Stelle ein Leerzeichen einzufuegen) Und: poste mal bitte den gesamten Inhalt vom main.err file, denn die relevanten Informationen sehe ich nicht Gruss, Thorsten.

Super, dass Du schon etwas hoerst. :) Aber mit dem sehen - hm - das VFD hat im Vergleich zu einem Standard Display ein voellig anderes Bus Interface. Es kann kein Read, stattdessen muss man die Busy-Leitung pollen. Auch die Kommandos - bspw. zum Setzen des Cursors - sehen voellig anders aus. Mit MIOS kann man solch ein Display ueber einen "Custom LCD Driver" ansteuern (siehe die app_lcd* Beispiele), aber um die Programmierung muesstest Du Dich selber kuemmern... Gruss, Thorsten.

Welches Flag hast Du genau geaendert, und was steht im Error File? (falls es nicht automatisch angezeigt wird: main.err) Du koenntest das .asm File umbenennen, das .hex File nimmt dann automatisch den neuen Namen an. Gruss, Thorsten.

Shuffle: if somebody could tell me how it is working exactly? (With examples - .mid files prefered) ;-) Your seq editing idea: I wouldn't be much effort for me to integrate such a step recording function, it could also be controlable from an external keyboard, so that only the Step Left/Right and Slide/Accent/Delete button is required. Or by a simple button replacement (just some additional "special function buttons", you know: up to 128 inputs are available ;-) Best Regards, Thorsten.

Pay.c: again - a nice idea! :) When you look into the source code you will notice that I've already implemented a pseudo random generator which is used in "Random Direction" mode. The advantage of this generator (in distance to a "true random" gen) is, that it works deterministic - it can be reset, e.g. via MIDI Start, and this makes random sequences reproducible. It shouldn't be a problem to use this generator also for random shifts - since one step takes 6 MIDI clocks (when the divider is set to 1), the groove feature makes only sense from -5 to +5, other values could produce a random value, e.g.: +6 - random from 0..2, +7: random from 0..5, -6: random from -0..-2 -7: random from -0..-5 -8: random from -5..+5 Nomical: patterns can already be changed within less than 1 mS - so in sync of course - latency was one of my highest priorities during the implementation of the sequencer engine. Songs are nothing else than chains of patterns (with loops from 1 to 16), it starts immediately, so no issue. 16 track sequencer: everything is possible ;-) BUT: only with some disadvantages, which I don't want to consider in my implementation. With 16 tracks it wouldn't be possible to store the whole pattern in RAM. The sequencer core has to read the pattern directly from EEPROM instead. This has no timing disadvantages (remember that sending a MIDI event takes 1 mS, an EEPROM value can be read within 10 uS...), but it makes realtime editing via MIDI impossible. Most parts of the control surface handler would have to be changed, so that only the select track is buffered in RAM. Features like Morhphing wouldn't be possible anymore, since this requires a second data set of the layer values. The whole SysEx store structure would have to be changed to a new format, it wouldn't be possible to store 128 patches in a single BankStick, but only 32 or so... a second JSynth GUI would be required to take the changed data structure into account (note: realtime editing with JSynth wouldn't be possible anymore), and last but not least: a second documentation would be required and somebody who answers the questions to this different implementation. ;-) Just take this into account... And to repeat it for the guys who didn't read my other postings regarding the reason, why I only need a 4 track sequencer: I'm using it as creativity tool. Once a nice sequence "works", I record it with Logic, and the MBSEQ is free for the next track. Sooner or later I've to rearrange and mixdown the sequences anyhow, and for this an editor like Logic is much more efficient (yes, in this situation I really like to use a mouse). If you really want to record, play, arrange, mix a whole song with a standalone device, then you have to program something which has been done by Emagic or Steinberg 15 years ago - on the Atari ST (a second-hand Atari costs you less money and less effort) Arumblack: for every CC's you have to use a seperate track. But see above, why more than this doesn't make sense. It is possible to chain multiple MBSEQs (synced via MIDI clock), but it isn't possible to control them from a single control surface (it would have to save all editable parameters in RAM anyhow) Best Regards, Thorsten.

Duggle: yes, patterns can be edited in realtime via SysEx or CC (there are 4 dedicated MIDI channels for the layers and config data) - nice for testing :) Captain Hastings: you are right, this is something I forgot, the LCD requires some additional lines, so two cables (15 pin connector + power) are required :-/ Btw.: new function Groove button: to shift the 16 steps globally in positive or negative direction by +7/-8 MIDI clocks Morph and Groove will replace the MIDI and SysEx shortcut button (these menus are reachable with the menu button at the right side anyhow) Best Regards, Thorsten.

Yes, this is also possible, but more difficult because of the PIC16F quirks (banking, paging) and the very limited memory (I guess 50 bytes are free... ;-) I just sent you the firmware via email, meta.inc has to be edited with a common text editor and it has to be assembled with MPLAB V5.xx from the Microchip page Best Regards, Thorsten.

Dan: I just have ordered the parts @ Reichelt. Maybe the first release will be ready in 2 weeks, once I finished the breadboards :) Btw.: for this project I will use detented rotary encoders (the China ones which were organized by Ian Hurlock some time ago), since highest precission is required for tweaking the notes. They have an integrated push button, maybe I will use it for an additional function Pay.c: thanks for this very good input! transpose buttons: the beta version I sent you one week ago already features a transpose function for each track. When enabled, 32 notes are strechted over the whole pot range and can be transposed octave-wise. This function will also be available in this variant (check the transpose button in the menu section). Ok, it should be a piece of cake to provide also a Transpose +/- button for the free assignable F-section (note: in fact every DIN input can be used as free assignable function button, so its not limmited to F1-F4) Reset: yes, important! Morph: great idea! Morphing between two patterns can be realized very easily, the morph value could be controlled either by the data wheel, or by an external modulation wheel, or by the velocity value of the played note (-> transpose and arpeggiator mode). For note values it could be usefull to switch between the note from Pattern A to Pattern B when a certain morphing level is reached. Morphing should be switchable (enable/disable) for all 12 layers seperately Captain Hastings: only a single core module will be required. The design will be extentable from: tiny: core module w/o any control function - especially nice as standalone sequencer or arpeggiator with predefined patterns, editable via a Java GUI (Win/Mac/Linux) minimal: core module, 1 2x16 LCD, 6 buttons and one rotary encoder (optional: two additional Inc/Dec buttons) connected via Port J5 (requires no DIN module) vintage: 64 pots, min. 32 buttons and 16 LEDs: the classic MB64 sequencer deluxe:see above extravagant: like above, but with 48 rotary encoders to control all 3 layers at the same time. However, with endless knobs such effort isn't really required, the layer switches are ergonomical enough Best Regards, Thorsten.

Perfect! :) Best Regards, Thorsten.

After the last beta-testing days with my MIOS based MIDIbox SEQ I noticed that so much advances functions have been added, that the sequences can only be edited ergonomically with a dedicated control surface - so, here my first try - feel free to add your comments: From the left to the right: Track buttons: I still won't use more than 4 tracks, since this an analogue style sequencer + arpeggiator and no groovebox. Therefore the 4 tracks can be selected directly with these buttons Layer buttons: to select the "Note number/CC Number", "Veclocity/CC Value" and "Gatelength" Layer. For TB303 fans: accent can be realized by varying the velocity, slide by varying the gatelength or by assigning a portamento controller to another track Mute button: to mute tracks and steps View button: to select different views on the displays ChngAll button: when pressed, one rotary encoder changes the values for all rotary encoders at the same time Reset button: resets the Layer values Mode Edit button: the multifunction buttons are used to play a note/controller Mode Pattern button: the multifunction buttons are used to select a pattern on-the-fly (from A-1 to h-8: 128 patterns) Mode Chain button: to select a chain of patterns (up to 16) Menu button: shortcut to jump into a menu directly 2 * 2x40 LCD: since a 2x16 display is really too small, I want to see all notes/values which are played rotary encoders: for a simple analogue style sequencer pots are ok, but the powerfull track/layer function really demands for endless knobs, otherwise the finetuning of a pattern doesn't make fun! Multifunction buttons: see above Data wheel: this rotary encoder replaces the Menu Left/Right buttons, provides faster data entry Select button: was "Snapshot" button in MB64 Menu button: was "Exit" button in MB64 F1-F4 buttons: free assignable buttons, can trigger MIDI events or any functions directly (e.g. "Mute all", "MIDI Clock Master/Slave", "Fwd", "Rwd") Start/Stop button: function should be clear Case: I will try to mount the panel on a common - flat! - computer keyboard. The case will only contain the control elements and DIN/DOUT modules, the other modules (CORE, AOUT, Power supply) will be put into a seperate box. Advantage: in this way the surface fits nice in front of my MIDIbox SID :) The core unit and the control surface will be connected via a 6-wire cable. Ok, thats all for today. ;-) Best Regards, Thorsten. P.S.: the 64-pot sequencer will still be provided by the MBSEQ application, also the 2x16 display - for people who don't plan to use all features so extensive like me. P.P.S.: the sequencer will also run without control surface - with a singe core module. In this configuration it can be configured from the Java frontend (JSynth).

The default pot assignments can be found in mb64_presets.inc LCD: very strange, no idea... Best Regards, Thorsten.

Hi Wilba, the reason why I drew this ground connection into the schematic is that I wanted to prevent that people like you who don't build this PSU, but taking the diagram as source of inspiration, forget a proper ground between the core modules. It's basically for the scenario where two cores are powered via J1 and connected via MBLink You will find such "prevention measures" very often in my schematics. E.g., the rectifier is normaly not required for a DC input voltage at J1, but I always draw it into my schematics, so that electronic beginners don't have to take care about the polarity or DC/AC supply Best Regards, Thorsten.

Habe es verstanden und als Inspiration aufgenommen, wird also in irgendeine spaetere Version einfliessen. Urspruenglich wollte ich es so auch in die PIC16F Version einbauen, aber da war kein Platz mehr im Flash... Gruss, Thorsten.

Is this the controller number, or the controller value? I guess that controller value, and this means that you just have to configure the encoder to mode "40 +/- speed" (0x40 is the hexadecimal value of 64) From the tutorial: Traktor is a from NI, isn't it? Best Regards, Thorsten.

Well, this is something which you haven't mentioned before. Yes, it makes always sense to upgrade the box to MIOS. Just order some free samples at the Microchip homepage and exchange the crystal - it costs you maybe 2 EUR, but brings you a lot of additional features :) Best Regards, Thorsten.

Hi Wilba, thats really something absolutely unexpected! This explains, why your SID module was so sensitive against spikes. Well done! :) Best Regards, Thorsten.

Hi, it seems that there is a problem with the first and the last 4051 of your AIN module. Did you also check the voltages on the 4051? Best Regards, Thorsten.

Congratulations, you've found a bug in MIOS. I will fix this for V1.5 Workaround: if a Time Out occurs, send a valid event, and MIOS will continue Best Regards, Thorsten.

Some part numbers can be found here: http://www.ucapps.de/midibox16e.html Search for "Availability of Rotary Encoders" Best Regards, Thorsten.

Hi, you should always tie the open analog pins to ground, thats saver Pots: see this picture http://www.midibox.org/users/tor_arne/midibox64_walkthrough/pots.jpg BankSticks: yes, A=0 and A=1 are correct, and DEFAULT_BANKSTICK_CS should be set to -1 Application: you can disable the menu navigation buttons by setting the DEFAULT_DIN_MENU_* values to unused (or invalid) pin numbers like 0x80, 0x81, ... Best Regards, Thorsten.

Hi Dominik, thats no bug, but a feature ;-) from the MIOS source: ;; --- special case: if target and current position <= 0x07, stop motor ;; (workaround for ALPS faders which never reach the 0x00 value) (0x07 in 10-bit resolution) But you also wrote: > even value changes to 127 were ignored. could you please send me a .mid file which reproduces this problem? Best Regards, Thorsten.