TK.

Das ist wirklich eine FAQ, die schon mehrmals beantwortet wurde, deshalb in Kuerze: vor allem bei ungerasterten Encodern kann MIOS die vierfache Aufloesung erzielen (siehe http://www.ucapps.de/mios/mios_encoder_modes.gif), und zusaetzlich gibt es dann auch noch die verschiedenen Speed Modes. Die funktionieren aehnlich wie bei einer Computer-Maus - schiebe die Maus mal langsam ueber den Tisch, der Pfeil wird sich sehr exakt ansteuern lassen. Bewege sie schneller, und der Pfeil huscht mit einer kurzen Handbewegung ueber den gesamten Bildschirm. Dieses Verhalten laesst sich auch bei allen MIOS Applikationen so einstellen und nach persoenlicher Vorliebe anpassen :) Gruss, Thorsten. WIKIMARKER

Maybe there is somebody in your environment or country who owns a C64 and/or a MIDIbox SID? Best Regards, Thorsten.

Short question: are you using the buttons in OnOff, OnOnly or Toggle mode? Because in OnOff they should behave very similar to MIDIO128 (the same routines are used) - the only difference is, that MIDIO128 uses a mixed form of the LED modes - LEDs are turned on/off with the buttons AND via external MIDI events (if enabled) Best Regards, Thorsten.

Some words to the idea of virtual XT's: each Unit requires a dedicated MIDI In/Out pair, this is one drawback, because the Core provides only one MIDI IO. Merging these events with an external MIDI merger (either PC software or hardware based) will lead to new problems, because the MIDI traffic caused by the host when meters are displayed is already so high, that two merged ports would lead to more than 100% of the possible MIDI bandwidth (bottleneck problem). There are solutions to overcome this, e.g. one or more MBHP_IIC_MIDI modules could be used as MIDI IO expander, or a USB connection could be realised. But the implementation effort is very high - to high for somebody, who is already happy with his MIDIbox LC ;-) Panasonic/Alps: the Panasonic faders are really great, but today I would still prefer the Alps faders due to the touch sensor - this is a very important feature, not at least because it prevents that values are sent when the fader is not touched - this allows to increase the resolution (because jittering values are not sent when you don't move the fader), and values are also not send due to case vibrations. Panasonic Faders with touch sensor: this would be ideal! Best Regards, Thorsten.

As mentioned in this posting: http://www.midibox.org/forum/index.php?topic=7104.0, you've propably uploaded an old .syx file, because the conversion lead to an error message. So, maybe your results will be different when you are trying a new .syx Pitch Bender/Aftertouch Events: maybe the MIDI-Ox parameter "SysEx delay after F7" is not high enough, in this case it can happen that invalid data is written into flash. This is a general problem when no BankStick is used (writing into flash takes much longer, and interrupts must be disabled, therefore new data cannot be received). There is a very simple solution (I know this sounds stupid, but it's the easiest one): upload the .syx 2 or 3 times, until it works. A better solution: write a software which waits for the SysEx response from the PIC before sending the next block... just want to say: nobody maintains SysEx upload tools anymore, anybody else has to do this in order to make the configuration more user friendly... As for the jitter: I think it is either related to your PSU (try the one of your MB64), or it is related to the wiring to the core. Maybe you could try out more and report new details, this could lead to a new idea what could go wrong... Best Regards, Thorsten.

Your .ini and .syx file was very helpful to analyse the problem. When you convert the .ini from a command shell, following error will be displayed: ERROR in section ENCS, line 345: MIDIBOX64E only offers 128 pot/encoder entries! This is because of a 129th entry, which is out of range: 129 = B0 16 [00-7F:40] "unused" DEC| This could be the reason why nothing changed, because the old .syx file won't be touched - it was the old one. I removed this "129" entry, and tried it on my MBLC - it worked. The strange thing is, that in your second posting above, there was no "129" entry, but maybe there was another error message? Can you reproduce this? Best Regards, Thorsten.

No, 0.01V are fine ;-) If the interconnection test is working, I cannot say what could cause such an effect. Are you able to test the SID on a C64? Best Regards, Thorsten.

Thank you :) Currently I'm mainly busy with testing all the new functions, which mostly results into programming "unplanned" new features (every session leads to new inspirations). But I guess that I will go for a release in about 2 months. However, before the public release, interested guys can already receive a snapshot .zip of the current development, so long they promise, that they won't report bugs or missing stuff that I already know ;-) Matteo: yes, only the PIC needs to be replaced, and at least one reduced MBHP_IIC_MIDI has to be added (MIDI Out only, the simple circuit). It's possible to route the tracks to different IIC modules, so it might make sense to build two or three of them. I will integrate a second MIDI Out into my own MBSEQ very soon, because this allows me to use different instruments without adjusting the MIDI channels all the time I'm trying different combinations. The "internal" (EUSART based) MIDI Out is available as fifth MIDI Out, but it only works without failures so long the sequencer doesn't receive MIDI data. Best Regards, Thorsten.

A video says more than thousand words :) -> Best Regards, Thorsten.

Propably the SID module is not correctly connected, what are the results with the interconnection test? Best Regards, Thorsten.

Ok, so the PIC is propably running, but the MIDI interconnections are not working. When you are doing (really) all the tests, you should be able to find out the root cause. Shortcut: most people just swap the pins on the MIDI In and/or Out jack Best Regards, Thorsten.

There is an even easier solution: just configure the right LED mode in MB64E (I assumed in my posting that you are already aware of this possibility) See also http://www.midibox.org/forum/index.php?topic=4981.0 See also http://www.midibox.org/forum/index.php?topic=6039.0 So, you want to display the MIDI status, and not the button status with the LEDs, which means, that the LED modes should be set to 16..23 Best Regards, Thorsten.

Wenn man die Rasterung entfernt, und den Encoder Modus NON_DETENTED einstellt, liefern sie 64 impulse. Und mit Hilfe des "Fast Speed Mode" wird progressiv beschleunigt, so dass ein Parametersweep ueber den gesamten Wertebereich mit einer Handdrehung durchaus drin ist. Gruss, Thorsten.

It works, even on my old Palm Vx :) But I would also prefer a slider, or better: dedicated menu screens for sound parameter settings with buttons and sliders for intuitive and especially fast usage :) Best Regards, Thorsten.

Hi Ben, yes, I tried a certain P&G Motorfader type some time ago, and the result wasn't very promissing - mainly, because the MBHP_MF module and the MIOS based motorfader driver is not suitable for such fast (and power consuming) faders. The complete details can be found here: http://www.ucapps.de/mbhp_mf.html As for the idea to use 64 level meters: the LC protocol provides only 8 meters and channel strips (Mute/Solo/Select/Rec pair). So, it won't work, even if I would enhance the firmware by additional events, because the whole handling relies on the host software. Best Regards, Thorsten.

Lies Dir bitte nochmal den Thread zur Control Extension genau durch - das Layout wird sich (dramatisch) aendern, und ich werde nicht vor naechstem Jahr daran arbeiten (vorher muss erstmal die MBSID V2 in trockenen Tuechern sein) Die Anordnung der Buttons/LEDs/Encoder wird so spaeter nicht funktionieren. Gruss, Thorsten.

So, the scan matrix sends MIDI events when you are running the example application sm_example1 stand alone, but it doesn't work when you are using the sm_simple.inc inside the MBSEQ application? Seems, that you forgot to insert the hooks into main.asm? (see the header of sm_simple.inc, examples can be found in the main.asm of sm_example1) Best Regards, Thorsten.

-> http://www.ucapps.de/mios/change_id_v1_9c.zip Best Regards, Thorsten.

So, you haven't built in the debug code like proposed above? (Sending MIDI events to display which button has been pressed...) Without such informations (saying "nothing happens") your comment is useless ;-) Best Regards, Thorsten.

Das ist ein Trugschluss, denn bereits der MRST# und der Startup Timer sorgen eine asynchronitaet (siehe Datasheet), die Latenzen von MIDI tuen ihr uebriges. Ausserdem moechte man ja gerade fuer einen analogen Sound keine einheitliche Phasenlage zwischen den Oszillatoren, und wenn man es dann doch mal ausprobieren moechte, kann man auch die OPS (Oscillator Phase Synchronisation) Flags setzen... Viel interessanter ist das gezielte verschieben der Phasen. Hierfuer hat Wilba einen Algorithmus entwickelt, mit dem die Phase stufenlos einstellbar ist. Wenn bspw. OSC2 gegenueber OSC1 um 33% versetzt wird, und OSC3 gegenueber OSC1 um 66%, und alle drei Oszillatoren anfangs mit der gleichen Frequenz laufen, dann ergibt sich in der Summe die dreifache Frequenz. Interessant wird es nun, wenn OSC2 und OSC3 leicht verstimmt werden, dann verschiebt sich dynamisch das Soundspektrum. Und noch interessanter wird es, wenn auf einem zweiten SID die Phasen ebenfalls verschoben sind, hier jedoch mit einem anderen Anfangswert. Der resultierende Stereoeffekt ist einfach fantastisch! (und wird in der MBSID V2 auch allgemein verfuegbar sein :)) Gruss, Thorsten.

Steht der Encoder Mode auch auf DETENTED (nicht DETENTED2)? Siehe auch http://www.ucapps.de/mios/mios_encoder_modes.gif Vielleicht liefert ein anderes Pinning bessere Ergebnisse. Zum Ausprobieren den Speed Mode am besten auf 0 lassen. Gruss, Thorsten.

PC PSUs are switching power supplies, they need a certain load to work correctly, and they intersperse some high frequency noise into the circuit, which has to be filtered out with coils and caps. There are people who tried this before, some had luck, some not... if you want it newbie friendly, then don't use a switching PSU... yes, there are jacks available which are doing this automatically - they shorten the input to ground when no plug is inside the jack. I never really used the Audio In... Best Regards, Thorsten.

It won't work if toggle is handled at both sides. Either MB64, or Traktor should toggle the button. Traktor should be prefered, so that the LED is always in-sync with the host setup - if the LED is not set correctly, then this is propably a bug in Traktor. Best Regards, Thorsten.

If you want to keep it simple, then just write: SM_NotifyToggle ;; button number (0x00..0x3f) in MIOS_PARAMETER1 ;; the selected track is: MIOS_PARAMETER1[5:4] swapf MIOS_PARAMETER1, W andlw 0x03 call MIOS_HLP_GetBitORMask ; each track has a dedicated bit, use the OR mask pattern for conversion iorlw 0xf0 ; (for track button hold detection bit 7-4 must be 0xf!) SET_BSR SEQ_BASE movwf SEQ_SELECTED_TRKS, BANKED ;; the GP button number is MIOS_PARAMETER1[3:0], we can mask this: movlw 0x0f andwf MIOS_PARAMETER1, F ;; branch to GP button handler goto SEQ_GP_Button [/code] (I haven't tried this code, propably you need to debug a little) Best Regards, Thorsten.

You could build some debugging code into your modifications in order to debug this. Simplest solution: just send a MIDI event which contains the button number and the value, e.g. B0 <button> <value> But remember: MIOS_MIDI* will change the BSR, it has to be changed back to "SET_BSR SEQ_BASE" after the MIOS_MIDI_TxBufferPut functions have been called Best Regards, Thorsten.