audiocommander

MIOS_MIDI_Begin und EndStream(); sind nur notwendig, wenn dazwischen auch MIOS_MIDI_TxBufferPut() kommt ;)

The screenshot on the download page shows line numbers ;)

Hi Robin, so; you solved your troubles with that function? I noticed you are making no use of curly brackets within if-statements. As this is no error, your function will work fine without, but it may increase readability of the code, if you'd use some brackets and indentation; the logic of the blocks gets a lot clearer... Moreover I found a problem with your for()-loop. As there are also no curly brackets set, I think this might not work as inteded? See the nested version with curly brackets set here; this is probably how the compiler interprets your code: [tt] unsigned char SetLed_NoDump(unsigned char low_pin, unsigned char high_pin, unsigned char canc_pin, unsigned char stored_pin, unsigned char pin, unsigned char pin_value ) { if (pin_value == 0) { // only react when button is pressed. //Is the current pin the same number as the stored pin? if(stored_pin == pin) { // alter the stored pin to the cancel pin allocated number for the group stored_pin = canc_pin; } else { // if stored_pin IS NOT the current pin // make the stored pin vale, the current pin value stored_pin = pin; // using i variable from 0 to 5 for(i=low_pin; i<=high_pin; i++) { //set all pins in the group to "O" MIOS_DOUT_PinSet0(i); if(stored_pin != canc_pin) { //provided the stored value of the pin is not equal to the cancel number //set the current stored pin value to a "1" MIOS_DOUT_PinSet1 (stored_pin); return (stored_pin); } } } } } [/tt] If my interpretation of the logic flow is right, there is a problem with the return value, because there are cases where nothing is returned! -- so in contrast, I think you want to write this, which would always return the stored_pin, and would so be a correct implementation: (as you can see, it differs only in indentation and proper setting of curly backets): [tt] unsigned char SetLed_NoDump(unsigned char low_pin, unsigned char high_pin, unsigned char canc_pin, unsigned char stored_pin, unsigned char pin, unsigned char pin_value ) { if (pin_value == 0) { // only react when button is pressed. //Is the current pin the same number as the stored pin? if(stored_pin == pin) { // alter the stored pin to the cancel pin allocated number for the group stored_pin = canc_pin; } else { // if stored_pin IS NOT the current pin // make the stored pin vale, the current pin value stored_pin = pin; // using i variable from 0 to 5 for(i=low_pin; i<=high_pin; i++) { //set all pins in the group to "O" MIOS_DOUT_PinSet0(i); } } if(stored_pin != canc_pin) { //provided the stored value of the pin is not equal to the cancel number //set the current stored pin value to a "1" MIOS_DOUT_PinSet1 (stored_pin); } } return (stored_pin); } [/tt] Cheers, Michael

Hello Robin, Thank you for sharing this! :) Colorized code is a very useful feature - and an internal backup-mechanism should be available for every editor ...but unfortunately is not so common; I'm using Xcode because it's a wonderful Integrated Development Environment; but I always have to do my backups manually... Best regards, Michael

na, ich schätze mal, dein Loopstep1A ist 0. Dann kommt die else-Schleife, der Loopstep1A wird auf 1 gesetzt, die LEDs werden geschalten und die Funktion beendet. Beim nächsten mal ist Loopstep1A 1 und der if-Teil der Schleife wird bearbeitet. Also im Prinzip macht es das, was da steht ;D Grüße, Michael Übrigens: wenn du mehrere ON/OFF switches speichern möchtest, dann solltest du nicht mehrere unsigned chars dafür nehmen, sondern ein sog. "Bitfeld". Damit kannst du in einer Struktur (struct) bis zu 8 AN/AUS Stadien speichern. Der Grund dafür ist, dass 1 unsigned char aus 8 Bytes besteht; bei sagen wir mal 8 Loopsteps wären das 64 Bytes. Als Bitfeld kann man das auf 8 Bytes erledigen. Aber Achtung! SDCC-Stolperfalle: SDCC unterstützt maximal 8 Byte lange Bitfelder; d.h. wenn du mehr als 8 bits brauchst, dann musst du mehrere Bitfelder erstellen; Wenn du massig Platz hast und nicht viele Features geplant sind, musst du das nicht unbedingt machen, es wäre aber die empfohlene Methode zum Speichern kleinbittiger Variablen. Das Beispiel dafür habe ich kürzlich schon mal in just diesem Thread gepostet: http://www.midibox.org/forum/index.php?topic=6871.msg50985#msg50985

unreachable code heißt, dass der code (in deinem Fall der else-Teil der Schleife) niemals erreicht werden kann. Du hast einen ganz einfachen Anfängerfehler gemacht, der auch vielen anderen noch häufig passiert: es heißt nicht = (ist) sondern == (ist gleich); das eine ist ein sog. Zuweisungsoperator (x = 1); das andere ein logischer Vergleichsoperator ( if(x == 1) ). ;) Grüße, Michael ps: wenn Loopstep1A 1 ist, brauchst du danach eigentlich nicht Loopstep1A = 1 schreiben... pps: noch ein Tipp: Variablen schreibt man gewöhnlich immer mit Kleinbuchstaben. Ich glaube in dem C-Buch gibt es auch ein paar coding-style Hinweise: z.B. - DEFINES - var oder myVar - MyFunction() Das muss man natürlich nicht machen, aber ein guter Style ist auch gut lesbar und beugt so vielen Flüchtigkeitsfehlern vor. Du kannst deine eigenen Funktionen oder Variablen auch gerne mit einem Präfix versehen, zb. MTE_Traktorizer_Play() oder mteCueStatus oder MTE_LCD_MESSAGE... (das wäre auch was feines für deine Traktorizer-bezogenen Wiki-Files ;) )

Hi Hexman :) As I don't own a MB64E, please see these comments as hints, not as hard facts: From the uCApps changelog: That means, Encoders are to be written in Entry 1-63, Pots in Entry 64-128. That has nothing to do with channels; it's just for the MIDI-Assignments (AFAIK). To enable Pots you have to enable some #defines in main.asm and recompile the application code: http://www.midibox.org/forum/index.php?topic=6395.0 Maybe someone who has built a MB64E with Pots can add some details here? You could also do another search of the forum, a quick peek revealed quite a lot posts about that topic: * http://www.midibox.org/forum/index.php?topic=6395.0 Testing AIN Board * http://www.midibox.org/forum/index.php?topic=7149.0 Mapping Buttons to Midi Ch * http://www.midibox.org/forum/index.php?topic=7104.0 Enabling Pots * http://www.midibox.org/forum/index.php?topic=6938.0 MB64E Encoders (...) best regards, Michael

Hi hexman. Just some name-clearings: A Pot is an analogue resistor, that's needed for an AIN-module. An Encoder is a digital rotary "stepper", as you correctly noted, for a DIN-module. It is sometimes called a "virtual pot", so don't let yourself confuse by that. And to your question: please take a look into our wiki, namely here: http://www.midibox.org/dokuwiki/doku.php?id=midibox64e I think that should pretty answer your question. The FAQ and the How-To-Start articles in the Basics/General section are not the badest lecture having read somewhen ;) Best regards, Michael

in Mathe war ich auch immer schlecht ;D 0x heißt einfach, dass es sich um eine Zahl im Hexadezimalen (16er) Zahlenraum handelt. D.h. es wird nicht wie im Dezimalen (10er) von 0 bis 9 gezählt und dann von 10 bis 19 usw..., sondern von 0 bis 15 (0,1,2,3,4,5,6,7,8,9,a,b,c,d,e,f). Wenn es geht, besorge dir mal einen Software-Taschenrechner, der das Umrechnen von Dezimal in Hexadezimal beherrscht, das ist bei Bitoperationen und Midi-Rechenzeugs immer von Vorteil! Verstehe ich richtig, dass du das nur bearbeitet haben möchtest, wenn DIN-Pin#10 gedrückt wird? Na, dann einfach: [tt] if(pin == 10) [/tt] oder: [tt]switch(pin) { case 10: // do this and that break; case 999: // wenn pin 999 gedrückt wird oder sonst ein pin, nur als beispiel... break; } [tt]

den Pin (am DOUT) schaltest du ja mit [tt]MIOS_DOUT_PinSet0(10);[/tt] MIOS_MIDI_TxBuffer ist natürlich eine Midi-Funktion: am besten, du schaust mal die hervorragenden Midi-Artikel in unserem Wiki an; da ist das Midi-Protokoll super beschrieben (wenn du da nocht nicht so sicher bist): kurz gesagt besteht eine Midi-Message aus zwei oder drei Bytes; wenn du Note_Ons sendest aus drei: 1. NOTE_ON auf CHANNEL x (i.d.F.: 0x9f => 0x90 + CH 0x0f) 2. Notenhöhe (Taste) (i.d.F.: 10) 3. Velocity (Notenlautstärke) (i.d.F.: 0x0 bzw. 0x7f) Grüße, AC

hmm, verstehe ich nicht... wenn du beidesmal [tt]MIOS_MIDI_TxBufferPut(10);[/tt] aufrufst, wird auch jedesmal 10 (A#-1) gesendet. Alles alles so, wie's da steht. dann noch ein tipp: [tt] if(pin_value != 0) [/tt] kannst du auch einfach so ausdrücken: [tt] if(pin_value) [/tt]; das wird dann bejaht, wenn pin_value größer als null ist, bzw. irgendeinen wert hat. I.d.F. wird es aber nur 1 sein. grüße, ac

na, mich irgendwo hin mit aufzunehmen ist nun wirklich nicht nötig (...nur vielleicht die aufblasbare Midibox... ;D haha ,nein auch nicht nötig :) ) also, ein #define ist streng genommen keine Variable, da sich ihr Wert nicht ändert und sie niemals den Status des ausführbaren Codes im PIC erreicht. Wenn der Code kompiliert wird, tauscht der Compiler einfach jedes Vorkommen des definiertes Wortes gegen den definierten "Inhalt" aus. Suchen/Ersetzen-Prinzp; das ist alles. also: für MONIA wird 0x9f eingesetzt. Dabei darfst du natürlich MONIA nicht als unsigned char variable deklarieren, denn das sind zwei verschiedene Dinge! Wenn du das #definierte MONIA schreibst, setzt der Compiler einfach 0x9f dahin. Du schreibst ja auch nicht myVar = unsigned char 0x9f ! Natürlich kannst du soviele #defines definieren, bis die das Programm abstürzt, es dient tatsächlich nur der besseren Lesbarkeit und dass man schnell bestimmte Werte ändern kann. Ist also auch gut für DIN_PIN_NUMMERN und ENCODER_NUMMERN, also alles, was sich mal so mit der Zeit ändern könnte... Es empfiehlt sich auch, sich der allgemeinen Schreibweise anzupassen, nach der defines grundsätzlich komplett groß geschrieben werden, damit man sie leicht erkennen und von Variablen unterscheiden kann. Grüße, Michael

ich mach die 100 und will die aufblasbare Midibox! ;D weil mir nämlich nochwas zum Code eingefallen ist: anstatt nämlich beim Senden von Midi-Messages die blanken Zahlen (z.B. [tt]0x02 // Controller xyf[/tt] ) zu schreiben, könnte man auch mit #defines arbeiten; also #define TR_MIDI_FASTFORWARD 0x02 erstens wird dann der Code lesbarer und zweitens kann man das auch superleicht ändern, ohne ein komplexes Menü schreiben zu müssen. sorry übrigens wenn ich hier was mit der Autorenschaft durcheinandergebracht habe, Wild_Weasel und MTE ;D Grüße, Michael

hallo :) super, dass ihr das dokumentiert! ich hab' mal in den code reingeschaut; der sieht ja gar nicht schlecht aus :) prinzipiell solltest du aber MIOS_LCD_Messages (wie in fast allen beispielen von TK gezeigt) mit einer displayNeedsRefresh-variable aktualisieren; einmal MIOS_LCD_Clear() braucht ziemlich lange. Das sollte so selten wie möglich passieren und aktualisierungen (z.b. die eine oder andere ziffer ändern), sollte im LCD_Display_Tick() passieren: // neue typendefinition typedef struct { refreshDisplay : 1; // 1bit lang: 0=FALSE, 1=TRUE irgendwasAnderes : 7; // 7bit lang: 0..127 } appStatus_t; // appStatus als globale variable exportieren extern appStatus_t appStatus; // appStatus deklarieren appStatus_t appStatus; void Init(void) { // lcd soll am anfang aktualisiert werden appStatus.refreshDisplay = 1; } void DISPLAY_Tick(void) { if (appStatus.refreshDisplay) { // irgendwas aktualisieren // ... // refresh zurücksetzen appStatus.refreshDisplay = 0; } } wenn nun das display aktualisiert werden soll setzt du appStatus.refreshDisplay auf TRUE (1). in deinem fall wirft das noch ein paar mehr fragen auf, denn im moment hast du zu jeder aktion eine eigene anzeige; angelegt werden sollte das aber wenn möglich mit ein paar variablen (z.b. der letzte encoder wert, der letzte din-pin mit dem letzten value usw...) das hätte auch den vorteil, dass du eine faktoreinstellung dazu nehmen könntest, um die geschwindigkeit zu erhöhen (in abhängigkeit von dem increment-wert z.B.)... naja nicht ganz durchdacht von mir, aber so als anstoß... und noch 'ne anmerkung zum Wiki: du solltest den link zu der seite beim einbinden irgendwie anders nennen, weil "c-programmierung" recht allgemein und der zweck der seite projektgebunden ist... das ist aber auch schon alles was ich (als notorischer wiki-rum-ordner) zu kritisieren habe ;D weiter so! je mehr die beispiel-code-basis wächst, umso besser! liebe grüße, michi

uhh, yeah... overworked... this would be an expensive box, connecting 128 LEDs to 32 AOUT modules ;D ...sorry for the misinformation, fstop ;D and thanks stryd for correcting this!

I'd stick to MTEs first suggestion. - Buttons are no problem at all, go into DIN-modules /up to 64 per module - Potentiometers should have linear 10k resistance, you could check these with a multimeter. If they got these values, you can directly connect up to 32 of them (AFAIR) to one AIN-module AINx4-module - LEDs go directly to AOUT-modules DOUT-modules - LCDs: check for type (Graphical/Character; there are some custom drivers available for graphical LCDs); in the worst case this can be exchanged completely - additional parts have to be checked for compatibility. there are some tricks however to connect non-fitting parts. If you find some strange parts, you could send some details! The question would be if you're interested in keeping the cd deck working and adding midi-functionality? Dunno what to do there; depends on the voltage-levels and functions inside (be careful if there are high voltages in there! can be lethal!!) Best regards, Michael

If you have an old, unused PC lying around at home, you can always cannibalize some unused parallel- or IDE-cables... it's an almost unlimited resource :)

well, I can't repeat it often enough: go and buy a temperature controlled iron. It does not need to be the most expensive, but esp. if you're trying to solder directly on ICs (which is needed for example for the FM/OPL project), you need to controll the current temperature or you're endangering the chips. I got this one: http://tinyurl.com/kgyvn (Link to reichelt.de). It costs 45 EUR and is quite perfect for all kind of jobs. Regards, Michael

Hi Seppoman! many thanks for your thoughts! :) I didn't know about the consumer-level and the DC-decoupling; I see now the difficulties that this method most probably implies. The things get even more weired in my head, because I actually try to get my skin-restistance based Kontaktstation wireless, and to extend it to four or more persons. So I thought it would be easy equipping two persons with plus poles and the other two with minus poles and a wireless transmitted signal, without having the need to build four microcontrolled senders (which would annoy me a bit) :-\ Maybe a possible workaround for the DC-decoupling would be to "encode" the signal in a simple sine-wave and transmit that to the core-station, there decoding (and interpolating) the wave with an OpAmp? ...that would widen the possibility of the kind of transmission; I'm thinking about a bunch of very cheap FM-transmitters for MP3-players I bought recently from ebay ;D (I know there should be a lot of noise, but maybe some interesting music comes out of it ;) ) However, I think I will experiment a bit; it seems to me, that holds a bunch of fresh ideas, even if I don't reach the aim I got in mind for it now :) ...and reminds me of the light-phone I found in a funny book of old technical inventions: this is a device that transmits sound with some kind of pre-industrial laser (sound -> membrane as microphone -> light from the sun, redirected through a lens, vibrates because of the membrane -> transmitted to receiver as light-beam -> lens-collecting the light -> photoresistive material produces electricity -> forced vibration of receiver-membrane!) :D ...I love this kind of stuff! However, I'll be back with some testing-reports... Thanks alot for your suggestions! Cheers, AC

it hasn't been clear to me, that you're trying to modify the mb64e, because in C there is also the possibilty to add an event-table... sorry, have to pass then, don't know asm/mb64e enough :-\

haha ;D nice to hear! I always loved my 3D-spectacles 8) http://en.wikipedia.org/wiki/Anaglyph_image http://www.dogfeathers.com/java/hyprcube.html

Hi Luke, how about trying C if you don't understand assembler (I don't understand Assember, too ;D)? There are examples on the bottom of the C-Page @uCApps.de, which describe what you want to do (send CC's, send NRPN). Or is there any particular reason, why you want to do this in Assembler? Regards, Michael

well, I've got no clue what "coleman cold heat" means, but if you're talking of an iron to solder with about 300 °C: !!! DO NEVER CHANGE THE TIP WHILE THE SOLDERING IRON IS ON !!! ...forgive me screaming and being that rigorous :), but first this is dangerous, because it's obviously quite hot – and second: I killed my first soldering station doing this. At first I thought it has been a coincidence, but afterwards I found again the manual (cleaning up the cupboard ;D), which said quite clearly, that the iron will overheat and damage the heater (death to the iron) if the tip is removed while it's on. Take care, Michael

I know the topic has been brought up quite a few times, but I would like to get your opinion on another way of wireless transmissions: all topics discussed until now, were about wireless midi transmission (btw: a wirless midi transmission system can be bought now from m-audio; as I've read some time ago!) – but as this requires multiple microcontrollers and serial transmissions, DACs and ADCs and seems like hell of work, time, experience and develpment, I thought about hijacking an A/V wireless transmission device: that means I want to send the analogue voltage of a sensor directly via 2.4GHz A/V-transmission to a receiver that feeds the voltage into the AIN-pin. I have some 2.4 GHz Audio/Video transmission devices here; the biggest problem should be to get the required 12V for the sender out of a batterypack. From what I've understood from the docs, a Line-Signal can transmit up to 1.3 V; which should be still sufficient to read out with my sensorizer; maybe a simple OpAmp can increase the signal later on, too... What do you think of that possibility? 2.4 GHz A/V transmission systems get more and more popular, and so they become quite affordable; Most devices (at least the ones I got from X10) provide up to 4 channels to select, so there could be 4 different AIN-devices... Does anybody know how many Volts the Line-In of a device can acutally handle in practial situations (will the input of 5V to a Line-In destroy a device?) Could it be harmful for the Core to put up to 5V Signal directly on the AIN-pin from a different power circuit? Thanks for your suggestions! Cheers, Michael

hm, red or green; it should be like the ol' 3d-glasses; green lets pass only the red light, red lets pass only the green light green is the "opposite" color of red; so there should be maximum contrast against red... but that basically depends on the color of the chars, not that they disappear, too ;D cheers, Michael