TK.

Hi Ian, which error messages do you mean exactly? Best Regards, Thorsten.

Hallo Wolfgang, die Informationen zur MIDIbox LC sind quer ueber das Forum verteilt ;-) Hier gibt es Photos: http://www.midibox.org/midibox_lc_photos/ Gruss, Thorsten.

Ok, das erklaert alles. Dein COM Interface wandelt die Baudrate von 38400 Baud (PC-Norm) auf 31250 Baud (MIDI-Norm) um - die Daten treffen also schneller ein, als sie ueber die MIDI Leitung weitergesendet werden koennen. Wenn der Hersteller keine Flusskontrolle vorgesehen hat, kann es schonmal vorkommen, dass bei der Baudratenwandlung der Eingangsbuffer ueberlaeuft, und somit Daten verloren gehen. Abhilfe: MIDI-Ox dazu bringen, dass waehrend der Uebertragung regelmaessig eine "Atempause" eingelegt wird - probiere mal verschiedene Werte fuer den Low Level Output Buffer (16, 32, 64, 128, 256, ...), und das Delay (1 mS - 20 mS) aus. Gruss, Thorsten.

With the MIDIbox Link concept you can cascade as much MIDIboxes as you want - the problem is the protocol defined by Mackie. It knows only "one channel" for transfering the control data. Programs like Logic Audio, Cubase, etc. are searching for one unit per port only, they are not prepared for handling more than one unit with a single MIDI In. So you see: it's software limited, but not by MIDIbox... no chance for a workaround, unless you would ask the big companies for help (but we all know the update policy of them :-/) However, if you see no chance to add additional MIDI In/Outs to your computer (Btw.: the MBHP_USB interface provides two In/Out ports), you can still use the linked boxes as generic controller. Best Regards, Thorsten.

Sende mal ein Ping-Kommando zum Core (F0 00 00 7E 40 00 0F F7), wenn etwas zurueckkommt, laeuft MIOS, und das Display ist nicht richtig angeschlossen. Falls nichts zurueckkommt, ueberpruefe das MIDI-Interface Deines PCs: den MIDI-Out zum MIDI-In zurueckfuehren, MIDI-Ox Sysex Tool starten, ein beliebiges .syx File starten und auf Send/Receive klicken - es muessen genausoviele Bytes ankommen wie gesendet wurden. Gruss, Thorsten.

Exactly! :) Every character set which consists of 256 characters allocates 2k, so you could store 8 different sets in flash and assign it to different scanline sections. A synchronization between multiple cores isn't realistic for this application. Main reason: the "goto" instruction which is required to poll a flag or a signal takes two cycles. This results to a 1-cycle error which will be visible on screen (jittering scanlines). It was a challenge to solve the jitter problem in the existing code - fortunately I found a solution which compensates the error (-> H_SYNC macro) For external, asynchronous signals a deterministic compensation isn't possible. Best Regards, Thorsten.

Hope that you take into account the the Mackie Protocol requires a dedicated MIDI port for every "Logic Control" Unit? Best Regards, Thorsten.

The program is the same, but the configuration is different. So every core requires it's individual .syx file Don't worry, the upload doesn't take longer than 5 seconds, and you are able to replace the setup stored in the internal flash more than 10.000 times... ;-) Best Regards, Thorsten.

displaying all pot values - a nice example, yes :) I just have evaluated what I said - good results - here two quick hacks: 40x25 56x25 In reality it looks better, the resolution of my digicam reduces the quality, and it's especially a rectangle frame on my TV and not a trapezoid ;-) 56x25 characters are the absolute maximum (concerning speed, memory, realtime behaviour) Best Regards, Thorsten.

the interaction with vmidibox hasn't been implemented yet, so yes: you have to program it directly into the MIOS application. Best Regards, Thorsten. P.S.: no comments anymore to the release date of the MB64 MIOS port

To prevent any rumours: For most applications this isn't true. External RAM requires a completely different "core module" concept for an external bus interface. The realization is easy, but the circuit would be too complex for beginners (due to the increased number of connections) and much more expensive! It would limit the number of free PIC pins so that they would have to be replaced by multiplexers and latches, attached on the bus. Since the effort for myself would be to high to support two different concepts, I will stay by the current solution and try to live with the limitations, hoping that Microchip releases new compatible derivatives with even more internal RAM in the next years. However, external RAM won't help here, the access times are at least 10 cycles (possibly more, depends on the hardware design), this would result to a resolution of maybe 32x64 pixels ;-) Expected resolution with internal memory (by using ROM fonts, I will try it this weekend): 300xYYY pixels (YYY only limited by the number of scanlines of your TV) -maybe more For comparison the possible resolution if more internal RAM would be available: ca 580xYYY But most TVs wouldn't be able to display it properly... Best Regards, Thorsten.

If the application doesn't setup the merger by itself, just add following code to the USER_Init function: For cores which are acting as "MIDIbox Forwarding Point(s)" USER_Init movlw MIOS_MIDI_MERGER_MBLINK_FP call MIOS_MIDI_MergerSet For the core which is acting as "MIDIbox Endpoint" USER_Init movlw MIOS_MIDI_MERGER_MBLINK_EP call MIOS_MIDI_MergerSet Best Regards, Thorsten.

Hi, no - you could use one DOUT register to select 2-of-16 digits at once (two digits selected at the same time), and another DOUT register (which drives the two 7-segment decoders) to send the patterns. Sure - this would increase the max. number of digits even more! It only requires some (small) modifications in the driver. Just begin to work with the digits and you will notice how easy they can be handled. :) It would be nice if you could write a report (could be uploaded to the MIDIbox portal) which describes your variations and gives some programming examples so that other people can don't have to re-invent the wheel. Best Regards, Thorsten.

Maybe it's easier to start with http://www.ucapps.de/tmp/mb64seq_snapshot.zip Best Regards, Thorsten.

Hi Ian, http://www.ucapps.de/tmp/mb64seq_snapshot.zip includes the framework for a mb64 style menu, MIDI Learn etc. will be included later Best Regards, Thorsten.

Later! :) Best Regards, Thorsten.

Hallo, der Bootstrap Loader funktioniert zumindest, Du kannst den JDM also schonmal beiseite legen. am besten gehst Du mal in Ruhe die Setup-Tips unter Concepts->MIOS->Bootstrap Loader durch. Wichtig sind vor allem folgende Punkte: MIDI-Ox muss so konfiguriert werden, dass keine Rueckkopplung (Feedback Loop) auftritt - die eingehenden MIDI-Daten duerfen nicht zum MIDI Out weitergeleitet werden im SysEx Configurations Menue muss "Delay after F7" auf mind. 750 mS eingestellt sein Die Output buffer size kann auf 2048 vergroessert werden (um den Transfer zu beschleunigen) Gruss, Thorsten.

In the next days the midibox.org domain (where this forum is hosted) will be reconnected to midibox.org So, if you are not able to reach this forum via http://www.midibox.org/forum,'>http://www.midibox.org/forum, please try http://www.midibox.org/forum instead The final URL will be available next week: http://forum.midibox.org Best Regards, Thorsten.

No I don't know the new album yet, but I will check it on the next trip through the CD store - thanks for the hint :) Some words to the improved resolution: I haven't taken into account that storing so much characters per line also costs too much RAM. Another problem is the "tblrd" instruction which takes 2 cycles instead of one - very bad for "balanced code" (a requirement for proper graphics). So a compromise would be an alternative mode with 40x25 ROM characters, and maybe another alternative mode which allows to split the screen in two halfs for a big and a small font. Let's check it next weekend ;-) Best Regards, Thorsten.

You mean: reusing the VIC from an old C64 -> next year ;-) Best Regards, Thorsten.

The resolution isn't limited by speed, but by the available RAM. However, the next version will support a hires mode with quadrubled resolution which will only work with "ROM fonts" and with 1 pixel distance between the 8x8 characters. This will be nice as replacement for the MIDIbox LC display, since exactly 56 characters can be displayed per line in this way. Grayscales: not possible since two pins cannot be stimulated at the same time when the shifting method (for highest speed) is used. Best Regards, Thorsten.

Alle Projekte, die unter "MBHP Projects" aufgelistet sind - ausser "MIDIbox SID" - wurden noch nicht auf MIOS portiert. Sie laufen nur auf einem PIC16F877, die Umsetzung auf MIOS ist fuer mich ein "Low priority task", wird aber bald geschehen, um solche Unklarheiten gar nicht erst aufkommen zu lassen. Bitte nicht nach dem Release Datum fragen, dazu gebe ich keine Auskunft mehr. Sicher ist nur, dass die PIC16F Firmwares nicht mehr erweitert werden. Alle Projekte die unter Concepts->MIOS->Download zu finden sind, laufen ausschliesslich auf dem PIC18F. Einige MIOS Applikationen bieten bereits wesentlich mehr als das alte PIC16F Geraffel... Beispiele: MIDIbox64: 64 potis, 64 buttons, 64 LEDs MIOS ain64_din128_dout128_v1_3: 64 potis, 128 buttons, 128 LEDs MIDIbox16E: 16 encoder mit 16 LED-Kraenzen MIOS enc_example3_v1_3: 64 encoder mit 64 LED Kraenzen Und dies sind eigentlich nur die Programmierbeispiele... ;-) Wer noch ein komfortables Menue, Baenke, verschiedene MIDI Protokolle usw. haben moechte und sich diese nicht selbst "mal schnell" in die Applikation reinprogrammieren kann/moechte, muss halt auf die Umsetzung warten... Houston (MIDIbox HN) und Logic Control Emulation (MIDIbox LC) laufen nur unter MIOS (->PIC18F) Das Control Surface Feature (Step A/B und C) der MIDIbox SID laeuft ebenfalls nur unter MIOS. Hoffe alle Klarheiten beseitigt zu haben ;-) Gruss, Thorsten.

Hallo, yep - in main.asm den CS_MENU_DISPLAY_ITEMS parameter auf "4" setzen: Viel Spass beim Schrauben :) Gruss, Thorsten.

No idea - I don't own such a keyboard and therefore don't have experiences which performance is really required... Best Regards, Thorsten.

I made some snapshots from my scope for a better understanding: This snapshot shows the trigger signal (CORE:J14) in relation to the DIN input signal of the 74HC165 when the touch sensor is not pressed. Due to the low capacitance the voltage level raises fast. This shows the DIN input signal when the touch sensor is pressed. Your finger leads to a higher capacitance, therefore the voltage level doesn't increase so fast anymore. The MIOS_SRIO_TS_Sensitivity value variys the pulse width in 200 nS steps. A higher value will lead to a a higher sensitivity, since it increases the charging time. Now some words to the sample point. The RC signal of the shift register in relation to the touch sensor trigger: the DIN value will be loaded with the rising edge of RC RC in relation to the DIN signal --- MIOS will sample a logic-1 when the voltage level of the DIN signal was higher than ca. 3.5V at the rising edge of RC The same when the touch sensor is pressed. The voltage is lower than 3.5V, therefore MIOS will scan a logic-0 To your questions: Yes, it will increase the danger of crosstalks. The DIN registers should be as near by the fingertips as possible (this means: shorter than 1m (meter)) Keyword: heuristic analysis ;-) I used a trimmer to determine the best value. Higher values will lead to (the damned) crosstalk effects, lower values lead to a poor sensitivity. It's the same for the sensitivity value (-> pulse width) offered by MIOS. I've no experiences with such modifications (I'm no analog expert). I guess that it won't make a difference, because the PIC already contains strong output drivers (up to 20 mA). If you run into problems with your very special touch sensors (I'm using this simple circuit for motorfaders), you could add Schmitt Triggers to improve the logic level "detection". They could possibly also help to eliminate the crosstalk problem (if it occurs...) Best Regards, Thorsten. P.S.: these pictures have been made with the touch sensors of my MIDIbox LC - 16 shift registers (=128 inputs) are connected in a chain, the touch sensors are the last in the chain, this explains the transients on the high-frequency RC signal