TK.

The upcoming STM32 based core module will provide an USB interface for MIDI and/or COM (-> e.g. for OSC) by default. In addition, you will get 2 MIDI IOs, CAN, IIC and several ports & drivers to external devices like SD Card, I2S (-> Audio Output), Ethernet, etc... and to all existing MBHP modules of course ;) Best Regards, Thorsten.

How about sending "dummy realtime messages" like 0xfe to add a defined delay between the SysEx commands. The DX7 shouldn't react one these events, and it doesn't hurt if one or more bytes get lost. This would be the most simple solution. All others are more complicated. The problem: since the MPROC parser and AIN/ENC/DIN handler are running with the same priority, it isn't possible to wait for an acknowledge message parsed from MPROC_NotifyReceivedByte() hook while waiting in DIN_NotifyToggle(), ENC_NotifyChange() or AIN_NotifyChange() for this message before continuing sending new SysEx messages (Sidenote: only MIOS32 will allow an elegant interaction between these tasks by using methods provided by a RTOS) Possible solutions for PIC based MIOS: a) program a "mailbox" system where the AIN/ENC/DIN handler puts new SysEx commands (in compressed format to save RAM) into a queue. In addition, program a SysEx parser which checks for acknowledge messages and notifies this to a queue handler. The queue handler has to be added to the Tick() hook. It checks for new messages, and sends them if the previous message has been acknowledged by the SysEx parser. Disadvantage: high RAM consumption b) there is a hidden hook in MIOS which allows you to parse incoming MIDI bytes interrupt driven. It has to be executed so fast as possible, therefore there is no (official) link to the C wrapper. In other words: this hook has to be programmed in assembly language. The parser which matches with your requirements is very simple, maybe it would already be sufficient to check for 0xf7? Using this method simplifies the programming model dramatically: - clear "F7" notifier (a volatile, global variable) - send SysEx message to DX7 - wait until "F7" notifier has been set to 1 by the interrupt driven MIDI receiver - done Disadvantage: you have to learn a bit assembly language, and I don't have the time to support you that much ;) Programming example for including the interrupt driven hook into a C application: http://svnmios.midibox.org/listing.php?repname=svn.mios&path=%2Ftrunk%2Fmodules%2Fmidi_rxtx_leds%2F Programming example for a tiny SysEx parser which resists in this hook: http://svnmios.midibox.org/filedetails.php?repname=svn.mios&path=%2Ftrunk%2Fapps%2Fexamples%2Fasm%2Fled_digits_mtc%2Fmtc.inc Best Regards, Thorsten.

Big news: Wilba got the package today! And this was really unexpected at least from my side, especially because I sent a claim form to the german post for tracking back the delivery, and only got the answer that it arrived Australia. Wilba checked the delivery in an Australian post office and got no helpful answer at all. This was one month ago... However, Wilba will forward the parts this week. :) Now I have a new issue: I got a lot of donations to compensate a financial loss which doesn't exist anymore. I just refunded the money, because I would feel guilty to use it for a different purpose, and it's free (no money loss for both sides) - if you want to support future development (e.g. for the new MBHP_CORE_STM32 module), just donate again :) Donated PCBs: how about the possibility to get some free 5x5 boards instead? I would re-sell the PCBs, and send the money to Kartoshka/Nils instead. Ok from your side? Best Regards, Thorsten.

You've access to the programmers Lounge - so, why not reading the articles about the upcoming 32bit approach? ;) Best Regards, Thorsten.

Btw.: the MIOS32 based version already supports RGB LEDs - as you can see: writing the app completely in C improves the expandability ;) Best Regards, Thorsten.

Looks simple - added to the Wishlist :) Best Regards, Thorsten.

Newsflash: see http://www.midibox.org/forum/index.php/topic,11387.msg102356.html#msg102356 Donations have been refunded - thank you anyhow!!! You guys are so great! :) A big thanks to all donators: Bugfight, Screaming Rabbit, Levon, Narwhal, amp1ron, SLP, kokiPsiho, StrydOne, /tilted/, Jack, Kartoshka, Enth, Doug Wellington, Flemming, Lief, Jan Forsmark I counted 22 PCB donations + ca. 200 EUR, which means that the loss is almost covered! :) Please send the PCBs back to me - this should be easier to handle, and it also gives me the possibility to mix new with old ones (why? details see below) Ok, I just have ordered 250 chips + 200 PCBs (I will hold some PCBs in stock for the next run) Final price: GM5 = 4.50 EUR, PCB = 3 EUR You have to pay within 3 weeks once I got the goods from Ploytec (I will inform you later about the expected delivery date) You will get a PM about all the paying/shipping options once this happens - don't ask now Updates on GM5: the new firmware allows full access over the EEPROM, so that up to 5 IOs can be defined with an own VID/PID and Device name - nothing else (yet). The EEPROM option itself is only a minor feature. It helps to separate the modules in the device list if more than 2 devices are connected to a PC, so that they don't appear under the same name. Instead of midibox.org or ploytec.com you could give it the name of your wife/girlfriend or whoever ;) Updates on PCB V1.2 (see MBHP_USB_GM5 page): - USB socket now grounded (but it will also work w/o this connection - it's just better) - two additional holes for shield of MIDI sockets (there are two different types, both are compatible now) - new jumper J8 which allows to select between midibox.org and ploytec.com configuration Note that the firmware of the previous GM5 run already featured the midibox.org configuration, but it wasn't communicated to me. Means: you can already select the midibox.org configuration by grounding IO4 with a small wire. The australians will partly get the new and donated PCB - only noticeable difference: some will appear as "ploytec.com", some others as "midibox.org" device by default. Best Regards, Thorsten.

I asked Ploytec: it's no problem to order 250 chips + PCBs now, and the next batch some weeks/months later. :) So, I will order them very soon. Please check the number of PCBs: http://www.midibox.org/dokuwiki/tk_gm5_bulkorder if you ordered an extension board as well: http://www.midibox.org/dokuwiki/gm5_expansion_5x5_board the small PCBs are not required - just remove the requested quantity from the tk_gm5_bulkorder list. Another - very sad - note: it seems that the package I sent to Wilba is lost. Therefore the australians haven't got their order yet. The package contained 46 GM5 chips and 34 PCBs and wasn't insured (damned!), accordingly I lost ca. 300 EUR! :( I sold the chips/PCBs for non-profit, which means that I have no margin to compensate the loss. But all affected people can be sure, that they will get their ordered parts soon w/o paying again (I just added them to the beginning of the list), and this time I will send it directly for fast and more secure shipping. This opens the question, which possibilities I have to get back the lost money: paying it from my own pocket since I was so naive to send the package uninsured and w/o tracking - in this case, I'm not sure if I'm willing to handle the next orders anymore due to the high risk of money loss or asking you for donations or increasing the price of GM5 from 4.17 EUR to 5 EUR, so that I'm able to get a margin to cover the costs Opinions? Newsflash: see http://www.midibox.org/forum/index.php/topic,11387.msg102356.html#msg102356 Donations have been refunded - thank you anyhow!!! Best Regards, Thorsten.

TEASER!

No, you would have to write "udata_acs" instead of "udata" However, there is no reason why not using BANKED memory range. It won't really have an impact on the performance of your function. Best Regards, Thorsten.

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.