ilmenator

Yes, this should work using the Midibox Link feature. If money doesn't matter... ;) Regards, ilmenator

Yes, this should work using the Midibox Link feature. If money doesn't matter... ;) Regards, ilmenator

Hi Ian, I noticed that on my footnote text - the guy is called Zvi L_i_f_s_h_i_t_z, look how he's spelled on the left. I have found no way to cure that behaviour.... ilmenator

Don't worry, leave it like it is now. As d2k says, the number of postings is not really relevant - maybe just a hint regarding the online time of each individual... ;) Best, ilmenator

Hi Thorsten, did you change the member ranking in some way? I noticed that people below 50 posts got set back to the "newbie" status, which kind of irritates me ??? Best, ilmenator

Hi Serge, it worked okay for me... Regards, ilmenator

Hi, go for a 9V model to be on the safe side. 6V is not enough for the 7805 to produce a stable 5V from it, 12V might get a little hot without the use of a cooling metal thing (don't know the exact word for that, sorry - mostly made out of aluminium to spread / dissipate the heat produced by the 7805). Best, ilmenator

It's a connector - you can either connect a plug to it, or you might solder the cable directly to it, which can be done from the upper side of the board. Handy if your board is already mounted somewhere and you decide to add a feature afterwards. Otherwise you can leave out the SIL (Single In Line) header and solder the cable directly to the board, which is mechanically less robust. Regards, ilmenator

Hallo, über die zu kleinen Löcher für den Gleichrichter hab ich mich auch schon geärgert - ich dachte aber, dass sei nur bei meinen beiden Platinen passiert. Scheint aber doch eher ein systematischer Fehler zu sein! Grüße, ilmenator

Wow, this looks really great - it's just about what I had in mind when I cleaned the old case. Now I hope that the v2 case is also big enough for all the electronics... Regards, ilmenator

Hi everybody, how about using the original C64's case for the MIDIbox SID? After ripping the 8580 out of my C64 v2 I either have the option to throw it away or make something out of it. I will try to use it as a case for the MIDIbox. Thorsten, could you post the Schaeffer Apparatebau File somewhere, so people could use this as a template (in order to not forget any holes...)? Thanks a lot, ilmenator

Hi nogginj, the B40C800 is one piece of hardware which consists of 4 diodes internally. For the capacitor: it is located on the input side of the circuit. You can find further information here: http://www.ucapps.de/mbhp_core.html All the best, ilmenator

Hi Major KONG, you can transmit values up to 14 bit by using RPNs (Registered Parameter Numbers) or NRPNs (Non-Registered Parameter Numbers), which are defined in the MIDI standard. Quite a lot of MIDI devices use these, because 128 steps is actually very little for some parameters (think of e.g. pitch bend). Regards, ilmenator

Hi Major KONG, you can transmit values up to 14 bit by using RPNs (Registered Parameter Numbers) or NRPNs (Non-Registered Parameter Numbers), which are defined in the MIDI standard. Quite a lot of MIDI devices use these, because 128 steps is actually very little for some parameters (think of e.g. pitch bend). Regards, ilmenator

Ist geschehen, viel Spaß damit. Natürlich würde ich mich über Feedback zu Fehlern freuen - dann geht das auch mal offiziell raus auf Torsten's Homepage. Grüße, ilmenator

Hallo moroe, bin noch nicht weitergekommen, falls du Interesse hast, schicke ich dir schonmal eine Version ohne Jittereater. Grüße, ilmenator

Die Platine zu kaufen ist keine Schande, im Zweifelsfall sogar umweltfreundlicher, und billiger als selber "from scratch" mit dem Aetzen anzufangen sowieso. Bei der reinen Platine ist kein PIC dabei. Wie das bei dem Bausatz ist, der auch irgendwo angeboten wird, weiss ich nicht. Das muessen die Verkaeufer selber sagen. Da das StudioMix immer dieselben Daten pro Regler schickt, braucht man eigentlich keine Learn-Funktion. Hart codiert im PIC tut es das auch. Falls du die andere Richtung meinst (CC nach NRPN): das habe ich nicht implementiert und werde es wohl auch nicht tun, da ich die Kiste ausschliesslich fuer Cubase nutze, und da kann ich jedem virtuellen Fader einen beliebigen Controller zuordnen. Thorsten hat aber in seinen Projekten bereits eine MIDI-Learn-Funktion drin, vielleicht kannst du die anpassen? Gruesse, ilmenator

Hallo monroe, da das Ganze ja ein explizit nichtkommerzielles Projekt ist, habe ich etwas Bauchschmerzen dabei, dir eine fertige Kiste zu verkaufen. Vielleicht sagt Thorsten was dazu? Natuerlich koennte ich gegen einen kleinen Unkostenbeitrag die PICs besorgen und die Firmware draufspielen, aber das macht dich natuerlich etwas unflexibel, was Verbesserungen angeht. Deshalb wuerde ich eher empfehlen, dass du dir gleich noch, wenn du zwei Core-Platinen bestellst, die JDM-Platine mit bestellst, die lag so bei 3,5 Euro oder sowas. Bauteile sind da kaum drauf, und beim Loeten kann man auch nichts falsch machen. Den Algorithmus von Wayne habe ich als 8-bit Variante auch schon implementiert, aber da gibt es ein paar Probleme mit der AUfloesung, weil die Fader vom Studiomix nicht die vollen 14 bit ausnutzen. Das fuehrt dann dazu, dass man so gut wie keinen Jitter mehr ausgleichen kann, wenn man nicht auf mehr bits geht. Da ist dann aber das Problem wiederum, dass der PIC mit 8bit Registern arbeitet - das ganze fuer 14- oder 16bit-Zahlen zu implementieren ist etwas aufwaendiger, zumal ich auch nicht der Assembler-Experte bin... Aber ich ueberlege gerade, was man alternativ zu dem Algorithmus von Wayne machen kann, mal schauen... Gruesse und viel Spass beim Loeten, ilmenator

Ja, die Moeglichkeit gibt es. Ich habe das bereits hinter mir und versuche nun, das Faderjittern in den Griff zu bekommen. Was man benoetigt sind zwei Core-Module, jeweils eines vor dem MIDI-Eingang und eines vor dem Ausgang des StudioMix. Beide arbeiten als MIDI-Filter, eines wandelt NRPNs in CCs, das andere macht das genau andersherum. Ein Beispiel ist auf der MIDI-Filter-Seite von Thorsten zu finden. Falls du nicht selber programmieren magst, kann ich dir gerne die beiden .hex-Dateien zukommen lassen, oder auch den Source-Code - den werde ich, wenn ich der Meinung bin, dass das halbwegs elegant programmiert ist, auch auf den ucapps-Seiten zur Verfuegung stellen, wenn Thorsten mitspielt ;). Allerdings musst du noch zwei Wochen warten, weil ich im Moment auf Reisen bin und nicht am meinen Heimrechner drankomme. In der englischsprachigen Abteilung dieses Forums gibt es da auch irgendwo einen Thread zu. ThomasT: NRPNs sind "NonRegistered Parameter Numbers", eine Moeglichkeit, Parameteraenderungen nicht nur in 7bit Aufloesung zu uebertragen, sondern mit sagenhaften 14bit. Gerade fuer Lautstaerkeveraenderungen ist sowas schon sehr angesagt. Ausserdem gibt es davon auch eine ganze Menge (14bit Stueck eben), deren Zuordnung auf spezifische Parameter nirgendwo festgelegt sind (im Gegensatz zu den RPNs, den "Registered Parameter Numbers"). Gruesse, ilmenator

I have actually been thinking about this. But you know, the unit is new, I loose my guarantee, and I'm not sure it is going to work the way I expect it... Maybe I could extract the logic circuits and just use the hardware (motor faders, buttons and incremental knobs). But then again, it might be easier to build a fader box from scratch... :P Well, I'll keep you informed. Thanks anyway, ilmenator

Now, I changed the ringbuffer's location as you suggested, everything's running smooth now. The problem with your 8-bit jitter-detection is, that the Studiomix's faders do not reach the upmost and downmost positions. This means that if I pull the fader down, I get a min. value of say 01 3F (High-Byte, Low-Byte), if I pull it up, it ends at say 7D 22. Now, if I convert the 14-bit values to 8 bit values, there is fewer than 1 bit left for jitter correction. This can clearly be seen in MIDI-Ox, where depending on JITTER_DELTA the values change in steps of 2 or 3 (= jumps in the fader movement), but not smoothly any more. The way I see it, it should be done this way: leave the values 14 bit, do some jitter correction, then scale the values down to 7 bit in such a way that 00 is the smallest value and 7F the highest value that is sent. I would be happy if there was an easier way, though!

Hi Thorsten, this could be the problem, the delta registers are like this: FMPV1 EQU 0x1f1 FMPV2 EQU 0x1f2 DELTA1 EQU 0x1f3 ; Jitter Eater Delta 1 DELTA2 EQU 0x1f4 ; Jitter Eater Delta 2 JITTER_DELTA EQU 0x1f5 ; max. Jitter Delta Still, it seems to be working when modifying the code like this, means testing with "skpnc" instead of "btfss": Jit_Test_2 ;; Jit_Test_1 was true (bit=1): JITTER_DELTA < DELTA1 ;; if JITTER_DELTA < DELTA2 movf DELTA2, W subwf JITTER_DELTA, W ; subtract DELTA2 from JITTER_DELTA, store result in W ;; is the result true ? skpnc goto Jit_Test_3 ; result not true: JITTER_DELTA >= DELTA2 goto Jit_Test_4 ; result true: JITTER_DELTA < DELTA2 The two Deltas are StudioMix specific, Wayne Legro describes two kinds of jitter: one is the normal jittering around one value, the other is jitter around two different values, one like e.g. around 10, the other around 80 (out of NRPN value total). I'll take a look at your code examples tomorrow - have to go to bed now... Good night, ilmenator

Hi, thanks for your reply. I got around to modifying the relevant registers in the debugger and can now simulate an incoming MIDI message. The problem seems to be within the following: I'm using the WGT and WLTEQ macros that you provide in macros.h to check a statement like value 1 > value 2 or value 1 =< value 2. ;; if JITTER_DELTA < DELTA2 movf DELTA2, W WLTEQ JITTER_DELTA, goto Jit_Test_4 ; result true: JITTER_DELTA < DELTA2 goto Jit_Test_3 ; result not true: JITTER_DELTA >= DELTA2 The problem is that the results sometimes do not seem to be right. Still, this cannot be a fault of your macro, because even with this code I get the same strange behaviour: movf DELTA2, W subwf JITTER_DELTA, W ; subtract DELTA2 from JITTER_DELTA, store result in W ;; is the result true ? btfss W, C goto Jit_Test_3 ; result not true: JITTER_DELTA >= DELTA2 goto Jit_Test_4 ; result true: JITTER_DELTA < DELTA2 I already exchanged the last two lines of code, which gives me a correct comparison in some cases - in other cases it is just the other way round. Is there something I overlook? When compiling, I get two warnings like: Command line: "C:\PROGRA~1\MPLAB\MPASMWIN.EXE /p16F877 /q C:\PROGRA~1\MPLAB\SM-CONV\MAIN.ASM" Warning[202] C:\PROGRAMME\MPLAB\SM-CONV\MACROS.H 32 : Argument out of range. Least significant bits used. Warning[202] C:\PROGRAMME\MPLAB\SM-CONV\MACROS.H 38 : Argument out of range. Least significant bits used. I do not get these warnings without use of the macros, but the effect is still the same - sometimes the comparison works okay, sometimes the result is just utterly wrong, depending on the two input values... ??? Any hint is much appreciated... this topic might also be discussed in german language, if this is easier to anyone... Sigh, ilmenator

Hi Thorsten, I'm trying to do some debugging for my filter code (NRPN to CC and vice versa, see other topic). Now, I would need to feed the debugger some MIDI bytes to see where the program branches to and what the registers are. Could you please tell me where to insert those MIDI bytes (say BF 63 23 BF 62 17 BF 06 03 BF 26 00 for a NRPN message) into the debugger? Which are the addresses/labels in the source code where the stimulus values are to be injected into the register? Which are the file register addresses/names where the values are to be injected? Btw, do you use the MPLAB environment for your work? Best regards, ilmenator

Hi Thorsten, you are right about your suspicion, the second MIDI event was sent by the new keyboard I tested the code with... Well, never try to verify something when you have two unknowns in your setup! The code will be published, but I don't have a site, so yours would be the ideal place. Still, there are some things missing, most of all a second core module to test the system as a whole. Otherwise, transformation in both directions works properly (NRPN to CC and vice versa), but jitter eating seems to make only sense when applying it to the NRPN values, which means working with 16 bit data. Here, I will have to do some more digging in the literature... Thanks a lot for the great platform you created, ilmenator