audiocommander

http://www.ubuntustudio.com/ and/or http://www.google.de/search?hl=de&q=%22ubuntu%20studio%22 ;) This looks great, btw! Cheers, Michael

I don't know what "code" is? When you don't know it, where does it come from? Just use [tt]unsigned char str[/tt] like I already written in my example above. If you're using pointers, you probably have to include the SDCC lib. Then leave away the const keyword and it's no constant anymore. Btw: here's a quite nice openBook for C in german language: http://www.galileocomputing.de/openbook/c_von_a_bis_z/c_007_007.htm#RxxobKap0070070400263C1F01E18C Because a char used as alphabetic letter is never negative. And my C-Book sais: char: 1 Byte, -128 to 127 or 0 to 255* signed char: 1 Byte, -128 to 127 unsigned char: 1 Byte, 0 to 255 * that 'or' is the problem. Do you know how SDCC or the PIC interprets this byte? I guess that SDCC will translate [tt]char[/tt] as a [tt]unsigned char[/tt]. But as you'll never know how SDCC might change it's behaviour in future or you might port your code to some other platform where it'll get interpreted as [tt]signed char[/tt], you will get problems if you're unclear. So try to be clear and use [tt]unsigned[/tt] whenever possible. believe me, it's better to deal with strings that have the same length. Why do you need a stringlength counter? The only reason I can think of are patch names. But even those are better defined with a certain length and prefilled with emtpy spaces. Regards, Michael

filmcomposer, pourquoi to ne utilise un pot 10k, simplement? quand tu programme toi application en C, il y a une fonction "AIN_NotifyChange(pin, pin_value)": pin_value est un numéro 10-bit (0 á 1023). C'est plus simple que utiliser douze pots á un AIN-pin. hope I got that right ;) Michael

Hi Rio, in 95% of all requests it's always the same: - "there is an error" - "it won't work" - "the compiler outputs an error message" Why don't you post this error message? ::) It gives us all the information necessary to get it right! Sorry for the Anstinker, now resuming in good mood ;D ;) : -> have you checked if your array is one byte longer than all chars occuring in this word? I guess so, because you use 41 chars, but it would explain the troubles. Btw: you don't have to care about the terminated null-char at the end of the array (exept when setting the array length). Perhaps the "invalid type" is your null-termination '\0' ? You may not add that to your array. Just leave it and it's fine (see examples below). first: you better want to use unsigned chars, that's a bit more economic than a (signed) char. It's not clear to me, what you are trying to do with this char array. I guess, the problem is that you are trying to print out words but refer to chars; it seems a bit mixed up. If you want to store the word "HELLO" it's: [tt]const unsigned char myWord[6] = { "HELLO" } [/tt] but it makes much more sense to use word arrays where you can easily select the word: [tt]const unsigned char myWords[3][6] = { "HELLO", "BYE..", "OKAY#" } [/tt] I have implemented this and printed the words like this: [tt]MIOS_LCD_PrintCString( (myWords[n]) ); [/tt] It works for me, so I don't know else what to say without knowing the exact errormessage. to 3: if you want to use strlen() and it's not included in the basic SDCC library, you will have to implement that by yourself. "Missing definition" explains this pretty well. It's like you wanted to use srand() or sin(); all of these well-known functions have to be included before you can use them. Cheers ;) Michael

Hi Bill, your code is missing a name, but besides that it's okay. When you are writing a typedef, you create a new type definion. So you don't have only unsigned chars or signed ints anymore but also mytype. You are using a bitfield as a structure. With 8 bits (maximum allowed value for SDCC!) it needs the same space as an unsigned char and you can store up to 8 boolean values. A Union is an either-or-thing. Than means, you can either ask ALL bits (and get the 8 bit number; it could also be [tt]unsigned char ALL[/tt] instead of an 8 bit struct) or you are asking the structure and can access every single declared byte. So the data inside the Union remains the same, just the outside form changes. Hm, I know, it sounds complicated, but actually it's very easy if you take a look at these example code snippets: Your typedef & declaration should look like that: // this is optional, but if you're used to booleans, it's a bit nicer: #define TRUE 1 #define FALSE 0 // typedef typedef union { unsigned char ALL; struct { unsigned oneBit : 1; unsigned theRest: 7; } } myType_t; // declaration myType_t myVar; // got a var 'myVar' of the type 'myType_t' now here are some example of using these vars: // usage myType.ALL = 0x1; // set all at once // or myType.oneBit = TRUE; // set every bit myType.theRest = FALSE; unsigned char c; c = myType.oneBit; // c is 1 c = myType.ALL; // c is 1 or another example: myType.oneBit = 0; myType.theRest = 1; c = myType.ALL; // ALL should be 2, cause the second bit is 1 (the first, third - seventh are all 0) // so you got: 0 0 0 0 0 1 0 => 0x2 myType.oneBit = 1; c = myType.ALL; // ALL is now 3 => 0 0 0 0 0 1 1 => 0x3 Cheers! Michael

yes, you got to change the current path before calling this; or submit the whole path; so in bash it would be either: [tt] cd /path/to/perl/script/ perl myscript.pl[/tt] or use the "shortcut": [tt]./myscript.pl [/tt] (cd is for change directory; If I remember right it's the same with DOS) or [tt] perl /path/to/perl/script/myscript.pl [/tt] If the script provides some output (which should normally be the case; eg. infos on expected parameters), then you should see something... Cheers, Michael

it's not that complicated if you know how to call them. I don't know if that's also valid for DOS, but in a bash terminal you must type [tt]./scriptname.pl[/tt] to run it. or you may try [tt]perl scriptname[/tt]; of course the filepaths have to match. You may peek into the file itself to lern about parameters you have to pass, but what I saw from these scripts, you may adapt them simply for you needs. Cheers, Michael

If you're programming in C you could take a look at the ACSimulator It's purely software based but seems to do what you need... Cheers, Michael

Hmm, I just found out about the "problem of the MAX-chips": The described "problems" nearly drove me mad the last days and now I got the explanation finally! Whenever I try to start the box and there's a MIDI-connection that's not active (ie no program on the PC started), the Box will usually not start. Whenever this happens, the Init() is delayed so long, the the SJ will produce garbage sounds 'cause somehow the whole Initialisation-Process will get scambled... I didn't notice that because I deactivated the LCD for debugging purposes; but this morning I saw clearly what's been the reason for all this :D So I think, the MAX-Chips should be fine ;) Cheers, Michael btw: the HandTracker is making great progress; I think it won't take long for a nice demo-video 8)

Hi Nym, yep, you should definitely make a search on this forum for Sharp, D-Beam, and GP2D; there are a bunch of topics about these sensors here. So I will just add some very few lines about that here: You should also check out the datasheet; the distance is actually much wider, but as the signal is not linear but a log-curve, this is it's main range. And there lies a tiny problem too, because if you don't restrict the range somehow it'll produce output all the time (in other words: the minimum threshold has to be taken into account). No, unfortunately not: the IR-Distance Sensor is not resistance-based, it outputs a Voltage. And the problem is that this Signal is not between 0 and 5 Vs but between (ca.) 0.4 to 3.2 V. So you will need an additional circuit if you want to exchange one of these sliders. However, you will find plenty of informations archived here... May I ask if you're from Japan? Because there are plenty of suppliers all around the world and if you're not from japan it sounds a bit expensive... best regards, Michael

Hi Mark, what should this formula do? The bracket is no mathmatical operator in C, so I don't know what you'd like to express with "2(x)" ??? I must admit, that I'm having troubles to follow what you want to do exactly, so it's hard to give any help (I know I could read all the threads you linked above, but I soon found out that the linkage level is quite deep, before grasping what's the point). Maybe you could conclude in one short sentece the aim of your question; this also makes it a good practice to get to an abstraction level needed for the program snippet ;) Anyway, it makes no sense spreading values between 55...126 to 0...127, because the resolution for the in-between steps is missing. In this case you'd have to read the values as 10-bit and then scale it to a lower value and do a 7bit conversion at the end. Although I think your approach with a lookup-table (array) seems quite fine for the task... So, here's one more thing: I wanted to express that you should send the compile error message last time, this would make things a lot easier. But I think I've found the error anyway ;D if (MIOS_AIN_Pin7bitGet(pin)=inputOutputMidiValues[0]) This is a widespread error, that happens also to the pro's from time to time: The logical comparison operator for equality ("is the same as") is this: == whereas the assignment operator that assigns the value of the right expression to the left side of the operator is this: = Tricky, isn't it :) Cheers, Michael

The compilers hints are the programmer's best friend ;)

Ja, denn dafür ist ja jetzt der MAX232 da ;) Man darf das 12V Signal nur nicht direkt an den seriellen Eingang des SpeakJet hängen, da der nur TTL-Level hat. Grüße, Michael

Genau, die linke Seite des Speakjets sollte komplett gejumpert sein (der mittlere muss nicht sein, stört aber auch nicht). Das von dir beschriebene Verhalten sollte nicht sein. Was genau für einen MAX-Chip hast du? Bringt es was, wenn du alles ausschaltest und die IIC-Verbindung unterbrichst? (sozusagen ein kompletter reset) und dann wieder alles verbindest und einschaltest? Grüße, Michael

Hallo Rio, freut mich, dass alles soweit gut geklappt hat :) Du kannst dich bei den Anschlüssen des RS232 Steckers auch ganz bequem nach meinem Plan richten, weil mir der prelim-Plan da auch Grübeleien beschert hatte ;) Ich habe in meinem Plan die Ansichten farblich codiert, so dass man nicht so leicht durcheinander kommt. Die Lötseite erkennst du an der normalen Schrift (Vorderseite gespiegelt). Aber noch besser: an 99% aller SUB-D Stecker sind die Pinzahlen vermerkt; schau mal ganz genau hin: die geprägten Pinzahlen (1,5,6,9) sollten mit der Zeichnung übereinstimmen. Die lila markierten Pins 4 und 6 sollten direkt am Stecker verbunden werden (kommen also nicht ans SJ-Modul). J4 ist kein Jumper in dem Sinne, dass eine Brücke draufzustecken wäre, sondern um zwei wichtige Pins gut erreichen zu können, die evtl. für spätere Versionen oder eigene Anpassungen benötigt werden: "1 SJ Out" ist leider ein Fehler, das ist noch übrig geblieben als es noch keinen J3 (Line-Out ohne LowPass) und keinen J5 (Line-Out mit LowPass) gab: D.h. J4 besteht aus: "D0 Ready" und "D1 Speaking" haben zwei Funktionen: - Ready: zeigt ob der Chip nach dem Einschalten bereit ist - Speaking: D1 ist high, wenn der Chip spricht und low, wenn nicht. Damit könnte man ein visuelles Feedback geben oder Mundbewegungen synchronisieren. Oder man kann den Chip (via EEPROM settings) so programmieren, dass D0 und D1 als Datenausgänge verwendet werden. Hoffe das hilft erst mal, Viele Grüße, Michael

hi chriss, it's not so hard to read this :) it's like this: [tt]filename:line:level{warning,message,error} [error-id] explanation[/tt] 416: CS_MENU_PARAMETER_ENTRY MACRO value, max, cursor, width, hook 417: db value, max 418: db cursor, width 419: dw hook 420: ENDM Hm, maybe we got a new keyword here? I'd think that [tt]dw hook[/tt] is a goto-like instruction? Then it would be the same "errortype" like IFSET, BIFSET and so on... However, I bet it's the reason for this error, that actually keeps the hex file from being generated: I must look this up before I can say anything valueable; but I must admit my time is currently very limited. If you're patient, you could wait some days/weeks until I come around to make some checkings, if you need it at once, you could try to "resolve" this macro manually. It seems it's not occurring too often... At least it seems to be just one error and the script solved 853 occurences 8) :D Best regards, Michael

cool, thanks a lot for the suggestions! I updated the pl script. There were some more warnings when I tried with the FM source, but at least a hex file was generated... :) And I detected two more errors (in the script) while converting MIOS v1_9c, but I'll look into that as soon as I have some more time, and maybe I'll implement some error checking methods. When the script runs fine, I'll put it to the Wiki. There's also some more good news regarding the differing hex files: My testings revealed that – as far as I can say until now – only sources written for the PIC16F are wrong. It seems all sources for PIC18F's can be compiled well with gpasm! :) Best regards, Michael

Hi Vincent, ahh... back from eating (way too much... burps... ;D ) the PIC18F4520 has some functionalities that makes it a good candidate for USB based projects, but AFAIK it has (like the PIC18F4620) the so known EUSART bug; you might want to search the forum for EUSART to find out more about that. I got not the best knowledge about this, but AFAIK both chips may send some garbage bits from time to time which makes them quite unuseable for MIDI based projects. The only PIC18F chip that does not have the EUSART bug is the PIC18F452. I also once made a wrong order ;( However, there is a workaround: the MBHP IIC Midi Module. It's connected by IIC (or I2C) to the Core and handles all the MIDI stuff... Don't know if it's worth to build an extra module that costs ~5 to 10 EUR to save 8 EUR for the wrong PIC :-\ If you're not using critical Midi stuff, you could just try the PIC18F4520; in terms of hardware it should be fully compatible to the 18F452. If you follow the adaption steps for the PIC18F4620 that can be found on the Wiki (see Application Development section), you will easily find the options in the relevant sources to compile the bootloader and MIOS for the PIC18F4520. The worst case for the EUSART bug I can think of, is an unwanted or wrong Program Change. I would not mind a scrambled CC and most apps ignore invalid MIDI instructions anyway... so, I guess it might be worth a try ;) Good to hear this issue is solved so fast :) Cheers, Michael

Just a quick reply, 'cause I got to leave: yes, these are different ones. You'll need the PIC18F452 to work or use a modified bootloader :) best regards, Michael

hmm, an EMU sounds not like a cheap DELL interface, so I wouldn't bet this is the answer. Besides the fact that it's working with a PIC18F4620 (I guess you mean a -4620 and not a -462, right? And the other one is a PIC18F452 and not a PIC18F4520, because that small zero makes a different chip :) !) Some basic questions first (you haven't mentioned it): - Are you aware of the fact that there are different bootloaders for the PIC18F4620 and the PIC18F452? - What power supply are you using ( V / mA ) ? Cheers, Michael

well, I guess that, if there is a driver for your touchscreen available, it should be installable in any installation as long as it's for the same processor type. btw: that dynebolic.org link is not working for me, but what I read from other sides, this sounds quite well: special kernel for low latenices and maybe useful for midiboxers also GCC and IDEs. I would try that, it's a LIVE-CD, can't get something better to check if that's the right thing for you (and works with your devices). Have to check out Ardour now ;D Cheers, Michael

Hi spanky, Well, I'm not sure about the exact options required to set up a MB64, but the merger does what it's name applies, it merges the incoming with the outgoing signals and sends out all of them. That way it is possible to build a chain of midi devices. You should enable the merger option only if you're connecting another device to the IN-port of your core or if you're planning to interconnect (link) different core. If your setup is PC->MB64->PC you should set the merger to OFF. best regards, Michael

I think an AOUT shouldn't be even be necessary, 'cause the PIC can output PWM signals that can be fed into a servo-motor control circuit; but I'm no pro in outputs (more focussed on inputs :) ) – that means I haven't generated a PWM yet, but if one got the right pins it shouldn't be too hard to find a C code snippet for that. Maybe something like this is already implemented in one of the available apps... The AIN position detection should mainly be a question of the mechanical construction design: eg. with an LED and a photoresistor (like it's done in some pedals) or the motor itself can be used as an input, 'cause it actually generates electricity when being turned. Or a magnetic field detector or pressure measurement... depends on the construction @MRE: you're talking about newbies and easy stuff and that's a totally different thing. If you're searching for quick and easy robotics, I can still recommend Mindstorms, that you can use for simple and quite advanced projects. There are lots of easy-to-assemble and click-and-drag-programs for beginners out there, but again: I was referring to question if it can be done with MIOS and my answer is: yes, definitely :D best regards, Michael

ahh cool 8) that's great to hear, Antimon :)