TK.

Due to technical reasons the MIDImerger only supports one hardware based MIDI IN, and one software based MIDI IN. It isn't possible to add more MIDI INs. Best Regards, Thorsten.

I like the case as well! :) RC4 and RC5 would be the first choice Best Regards, Thorsten.

The variables are probably not located in the ACCESS bank -> use SET_BSR to select the bank, add ", BANKED" after instructions which are accessing the variables. Under http://svnmios.midibox.org/listing.php?repname=svn.mios&path=%2Ftrunk%2Fmodules%2F you will find several programming examples, e.g. http://svnmios.midibox.org/filedetails.php?repname=svn.mios&path=%2Ftrunk%2Fmodules%2Fblm%2Fblm.inc (search for BANKED) Best Regards, Thorsten.

Some last words to the ideas behind the zoom functions: with 128 steps you would have to trigger the "Step View" (F3) button multiple times switch between the different 16 step pages. Thats unusable. This button will get a different purpose: press&hold it to zoom out the 16 step view - you will see an oversight over all 128 steps. Now press a GP button to zoom into a view. I'm also thinking about an alternative "scroll view" function by utilising the datawheel. Very quick page changes should be possible this way Best Regards, Thorsten.

A pattern consists of 4 tracks, and it depends on the selected resolution (clock dividers) if 128 steps are playing 8 bars or less or more. E.g., with MBSEQ V3 you are already able to play 16 bars with a single track if a clock divider of 64 is selected. Two notes per bar are played in this case. This is especially nice for a track which plays the base note for other tracks (note event sent via loopback to transposed tracks) You can also already select a clock divider of 4, which results into quadrupled speed. 32 steps are processed in 1/2 bar - but they are played superfast, so that microtimed beats can be easily created. Especially once the progression parameters are used in addition (so that for example the track will be varied over more than 4 bars) very nice effects can already be achieved. Another point (to answer some requests above): you can also already select odd divider values and predividers for different time scales. The track length can already be varied. All this for each track individually! - so, no need to overwork the concept here. There is only a strong need that people begin to understand the given possibilities ;) (sometimes I've the impression, that most of you only use straightforward tracks without different timing/length/progression values) In MBSEQ V4, we will get more steps, but I think that you can calculate by your own, how many bars can be played depending on the selected clock divider values (== resolution) Sorry, no time anymore to answer remaining questions - I've to prepare for holidays ;) For more requests I cannot say if it is possible or not anyhow, since the evaluation phase (checking the possibilities of the new micro by programming a lot of code) will take ca. 6 months. Thereafter I should have enough experiences to give realistic statements. Best Regards, Thorsten.

The live editing step sequencer concept requires static data structures stored in RAM. Let's say, each track would offer 16 layers with 128 steps, this would lead to a memory consumption of 2k for each track, and 32k for 16 tracks But the planned processor offers only 20k RAM (update: 64k RAM, 512k flash cost US $4 more - we will take this one) Another issue: storing 32k on SD Card would lead to unwanted latencies on pattern changes, regardless how much RAM is available But a 4th layer makes sense (I'm missing it as well) -> live control page Background story: two weeks ago I spent several hours to optimize MBSEQ V3 in order to get some free memory for this page. Especially because I've also some cool tempo/step progression manipulation ideas in my mind which could lead to very nice breakbeat effects as well. The page should combine the suggestions - a lot of parameters and trigger buttons so that everybody can search for his favourite ones. But at the end I only saved ca. 700 bytes - not enough. This was the day were I decided to move to a new platform... And a zoomed view, so that you can get an oversight over all bars. See above - I've some ideas as well, it won't be forgotten. haha! USB slave mode only Sure - the pattern slots not used by the song are free changable. Best Regards, Thorsten.

no problem, CAN/MBNet will be natively supported by MIOS32 (but why requesting it in this thread?) Best Regards, Thorsten.

Partly you are requesting features, which are already implemented. Hope that other people don't feel conused about that - everything written in the Manual is true ;) Best Regards, Thorsten.

We are currently working on the upcoming ARM based MIOS32 platform, and MIDIbox SEQ V4 will be one of the first projects which I will use for a feasibility study. It's too early to give you detailed informations about the final hardware decitions (and this topic shouldn't be discussed here), but the design goal is to find a solution which will only require to replace the MBHP_CORE module by a new one (MBHP_CORE_STM32), the remaining hardware can be re-used, no frontpanel changes are planned, etc. Expected upgrading costs: ca. 25..40 EUR (maximum) The new platform will allow to overcome the limitations of the PIC, especially the available memory and the execution speed. MBSEQ V4 will be implemented in C, so that it will be portable to different ARM derivatives (we will probably take a Cortex M3 based device), and even to a PC so that people are able to evaluate the firmware before building the hardware (given, that somebody else programs a graphical user interface) Update: GUI now available for MacOS - Cocoa is pure fun :) A first release can be expected in Q2 2009; I've some rough plans which features I could add in addition to the existing ones, but I wonder which ones you would like to see. My ideas so far: integrating the nice features you already requested for MBSEQ V3 (see bottom of CHANGELOG.txt and the MBSEQ V3.3 thread) more steps per track, at least 128 16 additional tracks for drums/percussions only, improved editing patterns stored on SD-Card, so that simple backup/file exchange is possible w/o using SysEx MIDI file import and export integrated MIDI file player support for USB; MIDI USB and/or optionally COM protocol (for OSC packages to a proxy) maybe also support for Ethernet (OSC and/or MIDI) using OSC not only for sound triggering, but also for remote controlling live recording with different quantisation strategies individual track/pattern/song/mixer channel names send SysEx patches to your synths (stored on SD-Card) Let's fill the memory ;) /Update: Comments to requested features here http://www.midibox.org/forum/index.php/topic,12186.msg105818.html#msg105818 Best Regards, Thorsten.

Yes, see http://svnmios.midibox.org/filedetails.php?repname=svn.mios&path=%2Ftrunk%2Fapps%2Fsequencers%2Fmidibox_seq_v3%2Fsrc%2Fseq_ext.inc E.g.: #if DEFAULT_ENABLE_J5_GATES movf GATES, W, BANKED xorlw 0xff call J5_IO_Set #endif [/code] will invert all pins [code] #if DEFAULT_ENABLE_J5_GATES movf GATES, W, BANKED xorlw 0x01 call J5_IO_Set #endif will only invert the first pin Best Regards, Thorsten.

MIOS_LCD_PrintCString was buggy in older skeleton versions You will find the new code at the bottom of this file: http://svnmios.midibox.org/filedetails.php?repname=svn.mios&path=%2Ftrunk%2Fmodules%2Fmios_wrapper%2Fmios_wrapper.asm However, I strongly recomment you to update your environment, so that you can develop applications based on the new platform. Otherwise it's really time consuming (for you and for us) if you run into trouble again. Best Regards, Thorsten.

You should also mention the advantages/disadvantages: advantage: less bytes have to be sent - but you won't notice a big difference on streams < 1k disadvantage: you have to implement an encoder/decoder to descramble the stream The nibble format increases the length of the stream, but it's easier to edit with already available MIDI SysEx tools (e.g. MIDI-Ox or Sounddiver). So, even people without programming knowledge can edit it. Therefore I provided this format as an example to transfer 8bit values instead of re-using the scrambling algorithm which I implemented into MIOS. Btw.: if you would take the MIOS scrambling format, you would be able to re-use already existing perl scripts ($MIOS_PATH/bin), and/or java code (see source code of MIOS Studio) Best Regards, Thorsten.

There are several technical reasons: the additional wire and FANIN load will increase the signal reflections on the SCLK and RCLK line, which are difficult to handle (shorter cables, no connectors between SRs, buffers, terminators). Probably also the SCLK frequency has to be reduced, which leads to a higher CPU load. Since the SRIO handler is running at the same priority level like the UART handler (to save resources), the serial transfer could lead to a MIDI IN buffer overun of it takes longer than ca. 600 uS. Also the SRIO handler itself is not simply scalable. You will notice this, once you are looking deeper into the code. Only simple solution I see if programming and testing effort doesn't matter: connect the second DIN/DOUT chain to different GPIO pins, and implement a new SRIO handler (at application level), which scans the two chains in alternating order. This would double the latency (2 mS instead of 1 mS), but it wouldn't affect the CPU load and wouldn't lead to too much additional HW effort. Two GPIOs could be saved, by sharing the So pin between the two DOUT chains, and buffering the SCLK signal between core and the DIN/DOUT chains (4 chains -> 4 buffers). Accordingly two free GPIOs for the second Si signal, and the RCLK (latch output) are required for this method. Best Regards, Thorsten.

Thats what I assumed ;) I'm not aware of a task priority issue in MBSID... therefore it was an obvious configuration error. Maybe you are not using MIOS_MIDI_BeginStream() and MIOS_MIDI_EndStream() in your application? Best Regards, Thorsten.

MBHP_TV war ein reiner WE Hack, weitere Versionen sind von meiner Seite aus nicht geplant. Fuer andere Zeichengroessen muss man den Algorithmus jeweils komplett neu programmieren. Soweit ich mich erinnern kann, habe ich das fuer einen kleineren Zeichensatz auch mal ausprobiert und es hat funtioniert, den Code habe ich jedoch nie released, weil die Leute langsam utopische Forderungen stellten, und ich laenglich erklaeren musste, warum bestimmte Features nicht realisierbar sind - dabei habe ich dann den Spass verloren. Gruss, Thorsten.

Scrambling is not required, you can also use these routines, which are easier to handle: http://svnmios.midibox.org/listing.php?repname=svn.mios&path=%2Ftrunk%2Fapps%2Fexamples%2Fsyx_dump%2F Details are described in the README.txt file Best Regards, Thorsten.

The microchip errata docs are partly incomplete. The bug is fixed on PIC18F2450 B5 and later Best Regards, Thorsten.

Strange, I don't see a reason why this doesn't work. MBLink is natively supported by MIOS, and you configured it correctly. Could you do some more debugging to find out, why a note is played after 7 seconds? Best Regards, Thorsten.

Hi Dario, thanks for asking! Since this is a one-time sale (especially not via EBay), it's ok for me. Best Regards, Thorsten.

I don't think, that the additional processing in the C program really affects the performance of your application, therefore it doesn't make much sense for me to evaluate a function I programmed ca. 5 years ago. You could try the hack by yourself, if it works fine - ok - if you find an error, then go the proposed way (I'm not planning to enhance the integrated merger of MIOS) Best Regards, Thorsten.

I'm using 1:1 prescaler in this example, so that the period time is easier to calculate. 1 mS == 10000 Maximum value for 1:1 prescaler is 65535 = 6.5535 mS got the point? At application level, there are no real advantages/disadvantages when using higher prescaler values. Just select a prescaler which fits your needs Best Regards, Thorsten.

This function allows you to disable the merger for the current and upcoming bytes until a new event begins. It's mainly intended for SysEx messages, and untested for other MIDI events. Many MIDIbox applications are using this inside the SysEx parser to allow to chain MIDIboxes with the same SysEx Header. However, as mentioned before: the programming example is the best solution for your usecase, otherwise the example wouldn't exist! Best Regards, Thorsten. P.S.: corrected wording - it could work, although I haven't intended this (and it's untested)

No, the merger is available since MIOS V1.0 The merger hack proposed by Durisian won't work perfectly, as merger data is forwarded before the hooks are called (corrected: it's forwarded after the MPROC_NotifyReceivedByte() hook has been called, so it could work, but I propably never tested this usecase during implementation phase...). For your usecase (modifying the incoming stream before forwarding it to MIDI Out), just use the example that you already found. Best Regards, Thorsten.

Klar, es spricht nichts dagegen. GM5 ersetzt Dir 5 separate MIDI Interfaces Mache ich aehnlich, siehe MBHP_LTC Modul. Jedoch verwende ich zwei Gatter, und verschalte sie zu einem Monoflop, so dass die LED nicht nur flackert, sondern laenger aufleuchtet (Delay ueber R/C konfigurierbar). Das ist kein Fehler, sondern technisch bedingt. Ploytec hatte urspruenglich gar nicht vorgesehen, den UART ueberhaupt einzusetzen. Nun ist er verfuegbar, und wir bekommen somit einen fuenften Port geschenkt - also nicht meckern, sondern freuen. ;) Gruss, Thorsten.

Ist bei mir genauso, und haengt wahrscheinlich damit zusammen, dass der 5. Port nicht emuliert, sondern von einem HW Peripheral bedient wird. Gruss, Thorsten.