TK.

Hallo Noskule, na, das erklaert eigentlich alles. Fuer die DIN Register kann man zwar eine Samplerate einstellen, doch leider nur in 1 mS Schritten. Fuer normale Encoder ist das auch voellig ausreichend. Schneller geht es nicht, weil die Routine dafuer nicht ausgelegt wurde. Doch bei Deinem Trackball kommen die Signale in so kurzen ABstaenden, dass sie wesentlich oefter abgetastet werden muessen. Evtl. alle 100 uS, damit auch kein 1->0/0->1 Uebergang verloren geht. Prinzipiell ist das kein Problem, doch hier musst Du wohl selbst Hand anlegen. Sprich: den Trackball am besten an zwei freie IO Pins anschliessen (ersparrt Dir den Treiber fuer das DIN Shiftregister) und in MIOS_Timer eine selbstgeschriebene Capturing Routine reinhaengen, die dann die Increments/Decrements ermittelt und an das Hauptprogramm uebergibt. Gruss, Thorsten.

Hi Pilo, the problem is, that you didn't mention which problems you are observing, therefore I cannot really give you an useful answer... However, the lcd_benchmark application demonstrates how to use TMR3 w/o interrupts. Best Regards, Thorsten.

Follow also the instructions under: http://www.ucapps.de/howto_debug_midi.html Best Regards, Thorsten.

Hi Dan, sure, you can. But note: if you are planning to build two MIDIbox LC, then every core module needs it dedicated IO pair (this is a limitation of the Logic Control protocol) or: if it is not required that the second core sends MIDI data to the host application, then there isn't a need for a MIDI chain. In this case you can just connect the MIDI Input of the second core (J11:MI) in parallel to the MIDI Input of the first core (J11:MI) Best Regards, Thorsten.

Of course, this is an important detail! Does it work, when the unused D0-D3 pins are connected to ground? Best Regards, Thorsten.

Hi, Scuzzle: of course, you've to take care that the correct baudrate is selected (it's a special menu entry in MB64/MB64E/MBMF). But there isn't a problem so long as the cables are not connected to the port which runs with the wrong baudrate. Pull-Up: two solutions: 1) cut the track between the Rx pin and R6. Use a resistor value which is much greater than R6, let's say 100k. Then it won't affect the optocoupler output signal or: 2) Don't cut the track directly at the Rx pin, but between IC2/Pin 6 and R6, so that you don't need an additional pull-up resistor. Since I would prefer method 2, here more details: Rx Pin: connected with R6 and the switch output IC2, Pin 6: connected with one switch input J11:MI: connected with the other switch input Once you get this running, please draw a schematic, add some comments and publish it at the MIDIbox Portal, since it could also be interesting for other people. Best Regards, Thorsten.

Ok, werde ich mir dann irgendwann mal anschauen und in der naechsten alpha fixen Gruss, Thorsten.

Hi Pilo, MIOS_Timer uses TMR3, thats already a 16 bit timer, and by using the MIOS_Timer_Init function you're able to control "allowed" parameters. Take care that USER_Timer is an interrupt service routine (Use FSR2, use IRQ_TMP*, etc...) Best Regards, Thorsten.

For the records: the problems are solved, he used an incompatible MIOS version (V1.4) with the MIDIbox64 firmware, which has been released after V1.4 It always makes sense to use the most recent releases, regardless if the new features are useful for you or not. Best Regards, Thorsten.

For the records: the problems are solved, he used an incompatible MIOS version (V1.4) with the MIDIbox64 firmware, which has been released after V1.4 It always makes sense to use the most recent releases, regardless if the new features are useful for you or not. Best Regards, Thorsten.

Hi Dan, Exactly. It will work once the "MIDI Merger" or "MBLink FP" option has been enabled. This can also be done from external by sending F0 00 00 7E 40 00 0D 01 00 58 28 00 01 00 00 00 00 00 00 F7 to the master core. With F0 00 00 7E 40 00 0D 01 00 58 28 00 00 00 00 00 00 00 00 F7 you can switch off the merger function again. Best Regards, Thorsten. FAQMARKER

Hi, did you also check that the 1k Pull-Up at Port J4 of the core module is connected proplery? Without this resistor the MIDIbox could switch to BankStick mode and would read random display/MIDI data Best Regards, Thorsten.

Hi, this should work - also during the PIC is running - but you have to add an additional pull-up resistor between the Rx pin and +5V in order to avoid random MIDI events during the switch phase. Best Regards, Thorsten. P.S.: the switch is only required for the Rx pin to change between the optocoupler and RS232 signal

Hi Wilba, I suggest 2.5mm aluminium, otherwise there is a high chance that this beautiful panel will bend during drilling. To the modulation matrix: since you arranged it at the left border, it makes sense to place the target selection buttons at the right side - for ergonomical reasons. You have to push two buttons to make a mod connection. E.g., to make a connection between E2 and the filter, you've to hold the filter button (with your forefinger) and to push the E2 button (with your thumb) For the envelope alternate mode I would suggest to use depth/attack/decay/curve/release parameter - in this order. Sustain is not affected by the curve, and you possibly don't want to switch back and forth between every curve adjustment (when changing the curve parameter, you have to adjust the assigned parts of the envelope anyhow - example: the decay will be much short with higher curve values, this has to be readjusted) Another hint: seppoman wrote a working VFD display driver for MIOS. His VFD runs much slower than a common LCD (ca. 4 times), but with the menu optimizations in alpha2 this issue has been solved (more intelligent display output routine) Best Regards, Thorsten.

In MBSEQ this has been realized by chaining the patterns. You can also set loop points, if you don't want to waste the pattern memory with equal patterns Best Regards, Thorsten.

You could also connect both SID modules to the core at the same time. They will play exactly the same sound, but this doesn't matter here. Just switch between the two Audio Outs. :) Best Regards, Thorsten.

Hallo, fein - somit sehe ich die Performance Probleme als geloest :) Zur "ARPSEQ Three": nein, das ist kein Performance, sondern ein SID Problem. Der Huellkurvengenerator verhaelt sich manchmal etwas seltsam. Du kannst das ueberpruefen, indem Du die Release Time bei allen drei Oszillatoren mal auf 0 zurueckdrehst. Hoerst Du den Unterschied? Den zweiten Punkt kann ich gerade nicht so ohne weiteres reproduzieren - meinst Du, dass bspw. im OSC Menue das S von "OPS" fehlen wuerde? Gruss, Thorsten.

Hi Dan, no reason for beeing confused. This is a feature for a guy who wants to switch between 6581 and 8580 w/o uploading a reconfigured application. The note about the core module is for people who design their own layout. If they also want to switch between the filter algorithms, they should not forget this pull-up resistor. Best Regards, Thorsten.

Hallo, so etwas laesst sich mit Meta Events sehr einfach realisieren (siehe mb64_meta.inc). Rufe einfach nach dem Senden des Strings die Funktion "MB64_BANK_Change" auf. Beispiel zum Wechseln nach Bank 2: (0x01) movlw 0x01 goto MB64_BANK_Change Gruss, Thorsten.

It sounds like the transfer works fine with 100 bytes/s, but you are uploading a currupt .syx file. Could you please try the midibox64.syx default setup which is part of the http://www.ucapps.de/midibox/mk_syx.zip package, just to ensure that the MIDI connection works properly? if this happens, it is maybe better to use a regular MIDI connection via optocouplers, so that the USB and MIDIbox voltage domains are seperated (I did the same with the MBHP_USB integated into my MIDIbox LC and MIDIbox SID). Or supply the USB module from the MIDIbox (remove the jumper near by the USB socket, and connect the "power IO" of the MBHP_USB with J2 of the core module) Best Regards, Thorsten.

But 250 bytes/s was with a PIC16F core, where only 14 bit are saved at once, no? Best Regards, Thorsten.

You've mixed some informations here. I will try to explain it in detail. This is wrong. There is enough RAM to handle 16 tracks, and the timings are extremly stable. Stable means here, that the SEQ kernel never needs more than 1 mS in worst case to handle all 16 tracks at a clock event (I optimized the routines by viewing the timeslices with a scope). This worst case happens on every 16th step, means: every 107 mS @ 140 BPM The sub ticks are consuming about 200 uS --- so, CPU power is really no issue (for comparison: I measured a jitter of ca. 2 mS when Logic Audio plays a MIDI track, regardless if I'm using my Hammerfall DSP MIDI Out, MIDIsport 2x2 MIDI Out or MBHP_USB MIDI Out, so this must be a problem with Windows...) To give you an expression: here is the data structure for one track record: ;; ----------------------------------- ;; track record structure SEQ_TRKSTATEx EQU 0x00 SEQ_TRKMUTED0x EQU 0x01 SEQ_TRKMUTED1x EQU 0x02 SEQ_TRKPLYTICKx EQU 0x03 SEQ_TRKSTEPx EQU 0x04 SEQ_TRKPOSx EQU 0x05 SEQ_TRKQUEUE0x EQU 0x06 SEQ_TRKQUEUE1x EQU 0x07 SEQ_TRKQUEUELx EQU 0x08 SEQ_TRKEVNT0x EQU 0x09 SEQ_TRKMODEx EQU 0x0a SEQ_TRKDIVLENx EQU 0x0b SEQ_TRKASSGNx EQU 0x0c SEQ_TRKTRANSPx EQU 0x0d SEQ_TRKGROOVEx EQU 0x0e SEQ_TRK_RESERVEDx EQU 0x0f SEQ_TRKRECORD_LAST EQU SEQ_TRK_RESERVEDx As you can see, one track allocates exactly 16 bytes, and so it wasn't a big deal to instanciate 16 of them which are working independent from each other. RAM consumption: 256 bytes ;; ----------------------------------- ;; Live Editing Tracks SEQ_TRK0 EQU 0x200 SEQ_TRK1 EQU SEQ_TRK0 + 1 * SEQ_TRKRECORD_LENGTH SEQ_TRK2 EQU SEQ_TRK0 + 2 * SEQ_TRKRECORD_LENGTH SEQ_TRK3 EQU SEQ_TRK0 + 3 * SEQ_TRKRECORD_LENGTH ;; Tracks played from EEPROM SEQ_TRK4 EQU SEQ_TRK0 + 4 * SEQ_TRKRECORD_LENGTH SEQ_TRK5 EQU SEQ_TRK0 + 5 * SEQ_TRKRECORD_LENGTH SEQ_TRK6 EQU SEQ_TRK0 + 6 * SEQ_TRKRECORD_LENGTH SEQ_TRK7 EQU SEQ_TRK0 + 7 * SEQ_TRKRECORD_LENGTH SEQ_TRK8 EQU SEQ_TRK0 + 8 * SEQ_TRKRECORD_LENGTH SEQ_TRK9 EQU SEQ_TRK0 + 9 * SEQ_TRKRECORD_LENGTH SEQ_TRK10 EQU SEQ_TRK0 + 10 * SEQ_TRKRECORD_LENGTH SEQ_TRK11 EQU SEQ_TRK0 + 11 * SEQ_TRKRECORD_LENGTH SEQ_TRK12 EQU SEQ_TRK0 + 12 * SEQ_TRKRECORD_LENGTH SEQ_TRK13 EQU SEQ_TRK0 + 13 * SEQ_TRKRECORD_LENGTH SEQ_TRK14 EQU SEQ_TRK0 + 14 * SEQ_TRKRECORD_LENGTH SEQ_TRK15 EQU SEQ_TRK0 + 15 * SEQ_TRKRECORD_LENGTH SEQ_TRK_END EQU SEQ_TRK0 + 16 * SEQ_TRKRECORD_LENGTH-1 But there is also some other kind of data, and these are the RAM consuming layer informations. Every track consists of three layers, assigned to the first MIDI byte (e.g. the Note number or CC#), the second MIDI byte (e.g. the Velocity or CC value) and the gatelength. ;; ----------------------------------- ;; pot layer A SEQ_POT_VALUES_A_00 EQU 0x1c0 ;; ... SEQ_POT_VALUES_A_3F EQU 0x1ff ;; ----------------------------------- ;; pot layer B SEQ_POT_VALUES_B_00 EQU 0x080 ;; ... SEQ_POT_VALUES_B_3F EQU 0x0bf ;; ----------------------------------- ;; pot layer C SEQ_POT_VALUES_C_00 EQU 0x0c0 ;; ... SEQ_POT_VALUES_C_3F EQU 0x0ff You can see: 4 tracks * 3 layers * 16 steps makes 192 bytes Also the control surface requires some bytes, and the basic sequencer functions. With MIOS you've 896 bytes free for an application (with some tricks ca. 128 bytes more) --- but this is not enough for storing the layers of the remaining 12 tracks in RAM. So my solution was (and I haven't taken it into account before, therefore I refused the 16 tracks requests first...) to read the layer informations of the other tracks directly from EEPROM. The resulting use case: every pattern consists of 4 tracks you can play 4 patterns at the same time you can edit only one pattern w/o timing problems you can switch between the patterns w/o timing problems you can connect multiple cores together and you can send patterns to another core, so that it will be played from this slave in sync with the master and now the limitation: when saving a pattern in EEPROM, the sequencer engine will stall for about 100 mS, this is an audible effect and not desired during a live performance. On the other hand: this doesn't hurt when you are using prepared patterns, modifiying it during the sequencer is running but don't want to save the changes... for the records: when a song switches to 4 different patterns, it takes ca 10 mS and is therfore not audible (the switching is synchronized with the sequencer engine, it will happen automatically at the end of a sequence when no note is played). I achived this performance by implementing a new MIOS function "MIOS_BANKSTICK_ReadPage" which will be part of the next MIOS version (MBSEQ uses a copy of this function, so that it will be compatible with the current MIOS version). A sequencer is not a synthesizer ;-) But like you can read above, it's easy to send a pattern to another core, so that it plays this pattern (if you really need more than 16 tracks...) Please explain me exactly which advantages you are expecting from this method. Which workflow is your target? There are a lot of enhanced methods to make such a sequencer more powerfull, you could either use external SRAM (e.g. 128k, battery buffered - I already wrote how to realize this), or you could implement a bidirectional interface between multiple cores, so that the master can request and submit informations from/to the slaves (-> see the companion core concept). This works fine so long as it is guaranteed that the slave can handle a request without much delay. And here is the problem --- the delay: I guess that a slave is always so busy, that a latency of less than 100 uS cannot be ensured --- so, forget the parallel core concept with bidirectional transfers, it doesn't really help. If you are thinking on an alternative sequencer concept, then maybe a sequencer which doesn't work step-based? Ok, such a sequencer definitely desires more RAM -> think about an external RAM extension Or you are thinking about a step sequencer which isn't so flexible like MBSEQ, but is optimized for dedicated jobs (e.g. a drum machine) -> don't use 3 layers, but think about another data format to save the step information. For example, you could run 32 tracks in parallel, every track assigned to a single note, velocity and gatelength. You only want to control the "mute status" and "accent". Result: instead of allocating 32 tracks * 3 layers * 16 steps = 1536 bytes for the layer information, you would only need 16 bit * 32 = 64 bytes for the accent flags plus 3 * 32 = 96 bytes for the note/velocity/gatelength which is used for the whole track (mute flags are already stored in the track record) Ok, I think this is enough to give you some impressions about the art of system programming ;-) Best Regards, Thorsten.

No Idea, I've asked Jamie how MIDI-Ox transfers the delayed data to the MIDI interface. Either MIDI-Ox needs an alternative mechanism (similar to Serges Loader, since the transfer is working with this tool), or MBHP_USB requires a special firmware for MIDI-Ox (but it's unclear if there is a way to "cheat" the M$ driver) Did you try Serge's Loader again (see message above)? It *must* work with 100 bytes/s Best Regards, Thorsten.

Update: I've contacted Jamie OConnell (the Author of MIDI-Ox), maybe there is a way to find a workaround. Best Regards, Thorsten.

So, in this case it could also be an issue with MIDI-Ox, and not with the windows itself. With WinXP I also installed the most recent MIDI-Ox version, maybe they changed something which makes it impossible anymore to upload SysEx bytewise. So, maybe better to try it with vmidibox again, because I've now ensured that it works properly under WinME and WinXP with the MBHP_USB - Reboot Windows - start vmidibox64 - select your MIDI interface - set the transfer rate to 100 bytes/s - send SysEx > if my midi box get blocked again...can i upload mios with primary bootloader using usb? Sure, but I don't see a reason for doing this. The code area hasn't been touched by this SysEx upload. You must differentiate between code upload via SysEx, and data upload via SysEx. Code upload is a MIOS specific feature and requires exactly the settings which I've described in my first article. Data upload is an application specific feature, and it can differ with every application. The data upload of MIDIbox64 has been written in a way which makes it compatible to the old PIC16F, with the disadvantage that the transfer rate is significantly lower. If I wouldn't have to take care about such compatibility issues (or if I would have the time to enhance vmidibox...), I could provide an alternative MB64 bank upload mechanism which works much faster, but I see no timeslot for this. However, in fact you should continue with vmidibox and try to find a solution. If it still doesn't work, you could ask Serge for help. Best Regards, Thorsten.