TK.

Ich bin kein Klangdesigner, vermute aber, dass man bei einem Slapbass die Lautstaerke eher mit einem Filter steuern wuerde, und hierbei evtl. auch die Resonanz variieren wuerde. Eigentlich muesste man auch ein wenig FM betreiben, doch dann sind doch wieder einzelne Oszillatoren fuer jeden Step notwendig, das ganze laeuft auf Physical Modelling hinaus, und wird richtig teuer! :-/ Ich habe mir fuer solche Klangexperimente Reaktor angeschafft - ist zwar nicht ganz guenstig, hat mir aber im Endeffekt eine Menge Geld an anderen Stellen gespart. Mit Reaktor hat man sehr schnell 16 Envelopes instanziiert, und die Steps lassen sich via MIDI oder mit einem internen Sequenzer ansteuern. So kann man herausfinden, ob sich die Muehe lohnt, das ganze mit analoger Elektronik aufzubauen. Ich bin nicht ganz auf den aktuellen Stand, aber evtl. gibt es heutzutage auch Freeware, mit der man aehnliche Klangexperimente betreiben kann? Gerade solche dinge lassen sich mit Reaktor sehr einfach und graphisch anspruchsvoll realisieren. Nachteil: man muss die Maus schupsen, um die Parameter zu aendern - oder man baut sich einen Controller, der die Parameter des Sequenzers via MIDI ansteuert. Gruss, Thorsten.

Welche Version vom Core Modul hast Du denn? V2 oder V3? (steht auf der Unterseite) Bei V3 sind keine Jumper mehr notwendig Gruss, Thorsten.

Hallo Andreas, theoretisch schon, man kann an die DOUT Module Reed Relais anschliessen, die schalten schnell und verbrauchen wenig Strom. Damit liessen sich bis zu 128 Knoten miteinander verknuepfen. Allerdings findet hierbei keine analoge Mischung statt - wenn bspw. X1 und X6 gleichzeitig auf Y5 geschaltet werden, kann es zu einem Kurzschluss kommen. Dies muesste durch die Firmware verhindert werden. Gruss, Thorsten.

Siehe auch dieses Posting: http://www.midibox.org/forum/index.php?topic=7255.0 Ich habe die neuen PICs als Samples erhalten, und sie mal kurz angetestet. Sieht nicht gut aus! Ich warte noch auf ein Statement von Microchip Gruss, Thorsten.

Hi Ole, nice to read that at least the rest is working! :) With which frequency are the LEDs flashing? Or do they flash in inperiodic cycles? Is a LCD connected to the core? Maybe you are inside a special menu? Best Regards, Thorsten.

It looks ok, maybe you compiled or selected the wrong .hex file? Which file date has the file you are uploading? Best Regards, Thorsten.

How do you measure the tempo? With the MIDI Clock Slave of MIDI-Ox, or by listening to the beats? Best Regards, Thorsten.

It's very dangerous to short the legs of a semiconductor, this mostly leads to damage of this part, and if you have bad luck, also of the surounding parts. This doesn't mean, that the other parts are damaged now, but nobody can really tell you, if they still working or not - this can only determined by experts. :-/ I think, the current situation is: when the green LED lights up, then the 5V domain (behind the 7805) is working ok, the problem must be somewhere between the LM317 and 7805 (see schematic). Yes, it doesn't matter if it is a 100uF/100V ecap and a TL317, they both should work. You are writing: where do you measure 9V? Before or after the LM317 (see schematic: "before" is the I pin, "after" is the O pin), voltages have to be measured against ground. Or more interesting: which voltage do you measure at J1, which at LM317:I, at LM317:O, at J2? Best Regards, Thorsten.

Thank you, I've added a link to the floorboard page! :) Best Regards, Thorsten.

Hi Mr. Reboot, the installation is so complicated since I had to change the bootloader concept in order to make it more future proven. In order to avoid, that 100es of users have to reprogram their PICs with a PIC burner, I developed an update mechanism which allows to update the bootloader via MIDI. I made it so secure and comfortable as possible (with CRC check before update, with MIDI messages sent via MIDI for people who don't own a LCD, etc..) but: the update can only work properly if you select the right .hex files which are matching in your situation. All the possible scenarios and the right selection of the .hex file is clearly documented in the README.txt file. If you select the wrong one, it can happen, that the bootloader will be destroyed in a way where is no solution anymore to reprogram it via MIDI. Such a worst case scenario - where the wrong .hex file has been uploaded - can be found here http://www.midibox.org/forum/index.php?topic=6560.0 I must say that I don't know how to avoid this without spending even more days in thinking about possible scenarios and building protections + new tools around this. In general all what people have to do is to read the README.txt - and if they are unsure - to ask which .hex file is the right one before trying anything out. However, "Reboot": I think there is a chance to revive your PIC. It seems that the problem was, that you tried to upload the new MIDIbox SID release with an older MIOS version - this cannot work, because one of the great advantages of MIOS V1.9 is, that it frees 1k of flash memory which is now used by the MBSID (see ChangeLog). Since you've used MIDI-Ox to upload the MBSID code (which is too large), you propably didn't see the error messages during the upload. The meaning of these messages are in your case, that you tried to write code into a protected area (they don't appear with MIOS V1.9). Now, after a reboot, the CS enabled application (which contains much more code) jumps into a location which doesn't contain valid code. Instead it contains the bootloader v1.1b code (in worst case the MBSID application jumps to the routine which erases the flash). So, this explains, why the version without CS worked properly. What to do now: don't panic! Don't try to upload any .hex file of the update package now before we know in which state your PIC is, and before we've confirmed which .hex file is the right one for reviving the PIC w/o reburning the bootloader So, which .hex files of the update package did you try to upload exactly? And a hint: please use MIOS Studio - it makes the upload more secure than MIDI-Ox Best Regards, Thorsten.

Hallo, Dafuer sind die Groovetemplates gedacht, ueber die man in V2 aus Speichergruenden lediglich den Shuffle einstellen kann. In V3 wird es 16 Templates geben. Die Delays und die Velocity-Modifikation werden fuer jeden einzelnen Step definiert. Ausser statischen Delays/Velocity-Mods gibt es auch einen variablen Parameter, den man dann live abaendern kann. Bspw. fuer das Delay: 0 VAR 0 VAR 0 VAR 0 VAR ... fuer den typischen Shuffle, wobei VAR live editierbar ist oder: 0 5 0 VAR 0 5 0 VAR fuer einen Shuffle, bei dem nur das Delay jeden 4. Steps veraenderbar ist, der rest steht vordefiniert im Flash Interessant wird es mit: Delay: 0 5 0 2 0 5 0 2 ... Velocity: VAR 75% VAR 125% VAR 75% VAR 125% ... 8 - die anzahl der moeglichen Gatetrigger muss ich noch evaluieren (Performancegeschichte) 64 Gates sind evtl. moeglich, muss ich aber noch testen. Bei den 8 CV Outs wird es bleiben Eine interessante Anwendung! Zuerst dachte ich mir, 16 EGs koennte man auch einfach durch einen einzigen EG ersetzen, der fuer jeden Parameter einen CV In bietet. Doch das haette den Nachteil, dass er nur monophon spielbar ist. 16 EGs polyphon spielbar - das macht aus jedem einfachen Piepser einen Killersynth! ;-) Problematisch koennte es bei parallel verschalteten EGs mit dem Stoerabstand (=Rauschen) werden Gruss, Thorsten.

Wenn Du bspw. die MIDIO128 hernimmst, dann muesstest Du an der Software selbst keine Aenderungen vornehmen - das gewuenschte Program Change Verhalten laesst sich mit mk_midio128_syx einstellen. Gruss, Thorsten.

Hallo Basti, wenn Du einen Brenner besitzt, dann kannst Du den Bootloader V1.2 auch direkt flashen, er befindet sich im Update Package unter: pic18f452/burner/bootloader_v1_2_pic18f452.hex Danach kannst Du via MIDI (nicht mit dem Brenner) MIOS aufspielen: pic18f452/midi/mios_v1_9c_pic18f452.hex Stelle mal unter Options->Timings ein langsameres Delay ein, dann sollte es auf Anhieb klappen. Ich habe Sprut vor Zeiten schonmal darauf hingewiesen, dass dieses Delay Setting von Newbies nicht gefunden wird, und das eine entspr. Meldung, oder ein automatisches Nachjustieren hilfreich waere, doch er hat sich davon nicht begeistert gezeigt. Deshalb hilft in diesem Fall nur: die MBHP_BURNER Seite genaustens durchlesen, unter Troubleshooting ist dieses Problem naemlich beschrieben. Das kann an so vielen Dingen liegen... hier findest Du eine detailierte Anleitung zum Troubleshooting: http://www.ucapps.de/howto_debug_midi.html sie hat schon jedem geholfen (weil jedes Problem, das bisher geloest wurde, dort aufgefuehrt ist - quasi das kollektive Wissen ;-) Gruss, Thorsten.

Stimmt nicht ganz - ohne __wparam werden saemtliche Parameter via Stack uebergeben, mit __wparam wird der erste Parameter im Arbeitsregister (WREG) uebergeben, und die restlichen im Stack. __wparam ist also besonders praktisch fuer MIOS Funktionen, da sie den ersten Parameter im WREG erwarten - im Gegensatz zu den mehrparametrigen Funktionen ist somit keine Vorbehandlung notwendig. Aus diesem Grund verwende ich konsequenterweise immer das __wparam Attribut, egal ob es Sinn macht oder nicht. Gruss, Thorsten.

The alternative software solution looks simple: the values transfered to the shift registers have to be inverted. This can be done with a "xorlw 0xff" one line above each "call MIOS_DOUT_SRSet" instruction in cs_menu_matrix.inc Best Regards, Thorsten.

Cimo: you don't need to modify the code, you just only need to use the mk_syx script, or Serge's Editor to send a new setup where the LEDs are mapped to incoming MIDI events. There are a number of different mapping possibilities: ################################################################################ # LED Map: assignes the LED shift registers to the Button Shift # registers or special values # Currently following values are supported: # 0 Default Setting (see Map below) # 1 Button Shift Register 1 (Button ID #1-#8) # 2 Button Shift Register 2 (Button ID #9-#16) # 3 Button Shift Register 3 (F1-F4 and Navigation Buttons: ID #17-#24) # 4 Button Shift Register 4 (Button ID #25-#32) # 5 Button Shift Register 5 (Button ID #33-#40) # 6 Button Shift Register 6 (Button ID #41-#48) # 7 Button Shift Register 7 (Button ID #49-#56) # 8 Button Shift Register 8 (Button ID #57-#64) # 9 Selected Group (1 of 8) # 10 Selected Bank (1 of 8) # 11-15 reserved # 16 MIDI Status received for Button ID #1-#8 # 17 MIDI Status received for Button ID #9-#16 # 18 MIDI Status received for Button ID #17-#24 # 19 MIDI Status received for Button ID #25-#32 # 20 MIDI Status received for Button ID #33-#40 # 21 MIDI Status received for Button ID #41-#48 # 22 MIDI Status received for Button ID #49-#56 # 23 MIDI Status received for Button ID #57-#64 # 24-31 reserved ################################################################################ [LED_MAP] LED_SR1 = 1 # (Button ID #1-#8) LED_SR2 = 2 # (Button ID #9-#16) LED_SR3 = 3 # (F1-F4 and Navigation Buttons: ID #17-#24) LED_SR4 = 4 # (Button ID #57-#64) LED_SR5 = 5 # (Button ID #25-#32) LED_SR6 = 6 # (Button ID #33-#40) LED_SR7 = 7 # (Button ID #41-#48) LED_SR8 = 8 # (Button ID #49-#56) [/code] pk: I don't know the MidiTizer so much, but if it sends any MIDI events in order to notify the states, then you only need to select the right mapping value in order to forward this information to LEDs Best Regards, Thorsten.

MTE: can you please bring this into the Wiki? Then I will refer to it from the floorboard page Best Regards, Thorsten.

For most CCs you can just reduce the range of the sent values - this can either be done with Serge's Editor or (the method I prefer) with the mk_syx script E.g., for the LFO1 Shape (CC15), you have to define the range 0..5 Only the "OSCx Octave" (CC#27, CC#35, CC#42) needs a special handling, since the CC goes from 0..127, but only the values 16, 28, 40, ... 112 are doing a change. For this you have to reduce the value range to 0..7, and the Meta handler has to send a CC based on this formula: 16 + (n*8 ) Best Regards, Thorsten.

Du koenntest auch Reed Relais verwenden, die lassen sich direkt ohne zusaetzlichen Treiber ansteuern. Ich habe das neulich mal ausprobiert, es funktioniert problemlos, und die Relais schalten erstaunlich schnell: http://www.ucapps.de/mbhp/mbhp_doutx1_reed_relays.jpg Gruss, Thorsten.

Hallo SysEx, schau mal bei Conrad - normalerweise ist dieser Laden nicht zu empfehlen (Apothekenpreise!), doch sie haben eine grosse Auswahl an Taster. Gruss, Thorsten.

See http://www.midibox.org/forum/index.php?topic=7440.0 Best Regards, Thorsten.

Hi, no, it's not possible to use encoders without DIN. But you don't need to build a PCB, just mount it on the same vectorboard to which the rotary encoder/button is mounted - the 74HC165 is just a small chip and costs about 0.35 EUR - no need to provide alternative solutions Best Regards, Thorsten.

Hallo Thomas, es wuerde mich wirklich sehr wundern, das wuerde die Performance von MIOS Applikationen ziemlich beeintraechtigen, und ich muesste das E Signal wackeln sehen, wenn ich es mir mit dem Scope anschaue - tut es aber nicht. Du koenntest ja mal spasseshalber auf MIOS_LCD_TypeSet(7, 0, 0) umschalten, und dann in mios_wrapper/app_lcd.inc die Debugmeldungen einbauen. Dann muesste man sehr genau sehen, wann der Cursor gesetzt wird Eine clevere Loesung! Ich wuerde so etwas jedoch lieber auf Applikationsseite belassen - ganz unter dem Motto "Never change a running system". So kann man den Retryalgorithmus anpassen, ohne dass MIOS noch weitere Parameter zur Verfuegung stellen muss. Gruss, Thorsten.

One thing that I've learned in the last years is: than earlier you are making changes on the hardware to improve the system, than less the effort at the end. You definitely want to do this sooner or later ;-) However, so long you are using C, I would propose to use an constant array of 8 bytes instead of a DSEQ_GetStepORMask(0) function - table accesses are faster, since there is no overhead for saving/restoring the stack. Best Regards, Thorsten.

And here the MIDIbox SID in a 19" case made by Twin-X! :)