audiocommander

In fact you could realize very advanced robotic projects with MIOS. Every robot consists of inputs (buttons / sensors; see wiki -> sensors) and some outputs (relays, motors, flexinol nitinol actuators (=> electronic muscles), lights, sound) via DOUT-modules, AOUT-modules or PWM (Pulse Width Modulation) Generation. You just have to take care that you never draw too much current directly out of the outputs. Just google around a bit and you'll find plenty of circuits and sources :) Or tell Santa Claus, you want a LEGO Mindstorms Robotic Set (I have an "old" RCX 2.0, there's also a brand new model available called NXT based on a 32bit ARM controller featuring FLASH memory, USB 2.0 and Bluetooth for ~150 EUR); you can experiment very well with it; there's also plenty of open source software, eg. NQC (Not Quite C) for Win, Linux and Mac (don't know though if it already works with the NXT!) and it's great for quick experimenting! http://shop.lego.com/Product/?p=9841 (in fact a very reduced version of my planned MIOS harmonizer is already running on my RCX ;D ) ...and lots of adults have chosen LEGO as their preferred way of working in the field of robotics, 'cause it's strictly modular, easy to build, very robust and easy to reuse. Indeed, there are some highly advanced thick technical books available... Cheers, Michael

Hi filmcomposer, the midibox64 is written is ASM, you might want to ask your question rather there than in the C-thread. If you want to write your own application in C, you can take a look at the bottom of the C-Page at ucApps.de, there are some C-code snippets that show you how to achieve this: http://www.ucapps.de/mios_c.html esp. this document "how to send Midi Events on Pot Movements": http://www.ucapps.de/mios_c_send_ain.html You can also download some C-based projects from the download-site and peek into the code. And (most important) take a look at the Midi-Section in the Wiki. It is explained in depth there how the Midi-Messages work and how you can work with channels: http://www.midibox.org/dokuwiki/doku.php?id=midi_specification hope this helps, best regards, Michael

[tt]"default" =>[/tt] ...and the reason of this posting [tt]"classic" =>[/tt] ...formerly and now active again. okay, I added a preview pic to poll... 'cause I don't like closed polls ;D Thanks again, Twin-X!!! You should receive an extra shiny Admin-Star :)

-->

yeah, noticed that too from the online demo :-\ However, I'm really keen on hooking this nice little thing up. But I have to finish the SJ first or I'm really guilty of vapor-ware ;D

wow! that's a really useful tip! :D thanks, wilba!

http://www.midibox.org/forum/index.php?topic=8052.0 haha... sorry :) yeah, back to topic: has anyone an idea if and where these buttons are available... and maybe some pricing info? (I know... too much) Cheers, Michael

--> --> --> --> -->

Hello everybody, in the mood for an interim report :) : I worked a lot on the application interface the last days. I've built in phoneme maps, jaw and tongue controls and now I'm waiting for an order to check it out with a matrix of four short distance sensors to control it by hand-movements in space (like talking handpuppets...) I'm currently adding some harmonic synthesis stuff to use the oscillators of the SJ as single-voiced mini-synth... for the puristic ones of us ;D And I decided to drop the recording possibilities, meaning the saving possibilities in the SpeakJets EEPROM, because: - I ordered a TTS256 speakJet compagnion chip, that receives text and shall be able to convert it by an integrated dictionary to allophone-"orders" sent to the SJ. - The second reason is that there's a PC program that does this quite good with a predefined dictionary, no need to reinvent the wheel... - and the last reason remains: if there's a slight error somewhere in my program, it might possibly lead to a destruction of the speakjets firmware. There is a rough buffer storage/previewer already implemented, but as I never used this the past weeks, I don't see a point in developing this further. While working on all that, my SoundGin arrived :D After reading the (excellent!, btw) datasheet of the SoundGin, I must say that this chip seems to have a lot more cool possibilities than the SpeakJet. There's an integrated note2freq table and the OSC control seems a lot more sophisticated. It has full envelope controls (Ctrl, Atack, Decay, Release) together with a bunch of informations how to synthesize vocal similar sounds. Of course it has also predefined phonemes, but unlike the speakjet it's not so limited to simple allophone-triggering. And finally, I really like the idea of having a simple powered device that could also be battery operated (compared to the +/-12 V FM or SID boxes)! I will surely port the control app to the SoundGin once I finished the SJ app! :) Cheers, Michael

I might also be that the voltage is not high enough! I experienced this lately when I plugged in some more sensors. The LCD did show only the initial blank bars. Increase the Voltage from 7.5 V to 9 V solved this issue. Please note though, that you shouldn't use more than 10 Vs. And please use a Multimeter to measure the voltage you send to the Core, because the printed numbers (on the universal power supplies) are often 2 to 5 Vs below the actual voltage. Regards, Michael

Hi Skyrise, right. Because there's heavy scaling and interpolation done and quite a bunch of variables are used per sensor/AIN Line, I restricted it to the 8 AIN lines available directly on the Core module (unmuxed mode). I think 32 AINs (in muxed mode by connecting an AIN module to the 8 "unmuxed" pins) would be too much for the current PIC... Well, the thing is: - the midibox mb64 is a specialized controller for buttons and AINs ranging from 0-5 V - the sensorizer is a specialized controller for AINs ranging from (whatever)-(whatever) V. No DINs here, because the DIN is already used to control the Hardware User Interface. I've built the sensorizer to be able to simply plug any sensor into my box and use it immediately. As my setup changes quite often (distance-, touch-, skinresistance-, capacity-sensors...), I just need the appropriate cable+connector and I'm ready to go. I also have another controller (microKONTROL) with sliders and encoders to fine-tune some settings... The specialized target functionality and the field of expertise is quite clear (talking of Sensorizer vs. MB64). I think that's good - and I don't want to get in "feature-conflict" with the default Midibox(es). It wouldn't be that hard to adapt the sensorizer if you were a programmer, but as you are not that good in that field, I'd recommend, you simply build both of them. As mentioned, the Sensorizer Basic consists of just a few hardware pieces, it should be easily integrateable. And remember, you can always reuse a core module for anything else if you're not confident. I can help you with enabling the MIDI-Merger in the sensorizer software, that means you could connect both boxes in row... Because there's just one sensor with analogue output listed – another idea: there's also the possibility to use a MB64/e and work on a circuit that improves the voltage of the sensor. For example, you could use a rail-to-rail opAmp to amplify signals to gain a maximum of 5Vs. If you can make the sensor send out 0-5Vs in the end and if we're talking of a maximum of one or two sensors, I'd think this would probably be the easiest method. hope this helps! ;) Best regards, Michael ps: maybe some additional infos for future sensorizer developments: The Core functionality will definitely remain (just sensors send MIDI), because I'd like to use remaining PIC resources to increase and strengthen the basic functionality. Ideas are: sending quantized Note Ons (and not only CCs), maybe in conjunction with harmonization...

sorry, I meant Plumstone for OSX (PPC). I mentioned it, because I saw there's also a new Intel-Version available. Although I heard Java opens source these days, I wouldn't bet on a version for OS 9 (I don't know many ppl with Classic OS, and those who use it are not related to programming at all :-\ if ya know what I mean... ) Best regards, Michael

from what I could read from the google cache, this "corporation" "took over" plumstone. I could see that it's still free; they just sell a midi-server. I think it's just a temporary problem. I can mail it to you if you'd pm me your address; I have 1.3 for PowerPC... cheers, Michael

Hi Teun, you won't achieve that with the default AIN/Core-board; at least not without a hardware- (opamps) or software-implementation. But there is the Sensorizer, which seems to be exactly what you're looking for ;D I'm about to release the next version (sensorizer basic)... the HUI of the first version is a bit unpractical, but the newer small version is quite relyable and has been tested a lot over the past few months :) There are just basic hardware-modules: 1 core, 1 DINx4, 1 BankStick, 4 Encoders, 4 buttons, Pedal recommended... but there's no USB output, just Midi... and there's no AIN, because the maximum of 8 sensors can be connected directly to the Core. Here's a quote from the feature description:

Hi Robin, I'm using variables this way: variable declaration (or) declaration and initialisation This is done in the .c-file at the top, outside any function: [tt]unsigned char record_button_state;[/tt] (or) [tt]unsigned char record_button_state = 17;[/tt] The additional keyword "volatile" is used to tell the compiler that this variable may be changed in other places. So it's a good idea to add this for globals: [tt]volatile unsigned char record_button_state;[/tt] (or) [tt]volatile unsigned char record_button_state = 17;[/tt] global export Now we need to export the variable as global. This is normally done in the header-file or above the declaration. The global export may not initialize the value! [tt]extern volatile unsigned char record_button_state; // in myfile.h or on top of myfile.c volatile unsigned char record_button_state = 17; // in myfile.c[/tt] note that this is not only valid for variables, but also for functions. I hope this helps :) best regards, Michael ps: As I'm an autodidact, I always welcome any corrections or better explanations :)

Alles Gute!!! :D

hmm, that's really strange... there's definitely an issue with my GPASM config. I just upgraded to 0.13.4 but it still generates the same hex file as with 0.13.3 This is strange because I didn't have had any problems with C-projects. So it seems to be an issue with plain ASM-files only. I'm investigating this further, as soon as I have more time. however, I just burned the hex file from mess and it works like a charm. I noticed no more strange sounds and everything seems to work very robust. The adaption to the input-buffer of the SpeakJet is definetely a good idea! In the meanwhile here is the converted hex-file by mess to be used as firmware for the PIC16 chip: (many thanks for that, Michaël!!! :) ) :020000040000FA :0200000036299F :020008001429B9 :100010008316243098004030990083121A089030DB :100020009800B601B501B701BA01B901BB010800DA :100030000511051685113420342005155530990019 :100040008316981C21288312342034203420342035 :100050003420342034203420342034203420342000 :1000600034200512851508006400BC01BC0B36283D :1000700008003708080037085F3C0800B400360A5B :10008000603A031D603A840035060319080004082D :10009000B600103E84003408831780008313B70A2B :1000A0001E30BE000800B50A3508603A0319B501D4 :1000B0003508103E8400831700088313B703080037 :1000C0003B0808003B081F3C0800B8003A0A203AE9 :1000D000031D203A84003906031D71288B17380848 :1000E00065288B138B1B71280408BA00903E84008E :1000F0003808831780008313BB0A83160C168312FB :100100008B170800B90A3908203A0319B9013908D0 :10011000903E84001E30BD00831700088313BB038C :10012000080064006020031D922808008316981CB4 :1001300097288312990008003E080319A228BE03DD :100140000510A32805143D080319A928BD0385102F :10015000AA288514080083168E140E1483123630D4 :100160009400B720831694018312B2010800203056 :10017000061B0238861B043883169300831208007E :10018000831614088312B000301CFA28141FD328D9 :1001900083168B178B138B1BCA28141EC928831236 :1001A0001413130809291308B100B01AD828ED2830 :1001B0006220FD3E031C1417851A141731086520B0 :1001C000141FED2883168B178B138B1BE428141E2A :1001D000E32883121413130809298C1D0929831697 :1001E00014088312B000301C09298C118B138B1B4F :1001F000F628C6288B17B01A0129B20100300A214F :100200000929301D08298615B20A00300A2109295A :1002100014160800831614180B29831294139300E4 :10022000941F0E2914160800F000030E8301F1003C :100230000408F2008C1E1F298C121A083E20831617 :100240000C1E2E2983120C1E2E2939083A06031D76 :100250002C2983160C122E298220990083127208F1 :100260008400710E8300F00E700E090003308500CB :10027000213086008316E0308500D63086009B0151 :1002800007309C0083128316FF30810083120A0816 :1002900007388A0008201820AB2001309000831610 :1002A00020308C008D01831218121A081816C030E5 :1002B0008B00061064000C1C61290C10EC308F07B9 :1002C0009C208B138B1B61298C1D68298C11C020ED :1002D0008B17831614088312103903196129B7206C :1002E000392003197529532065205A2983160317CD :1002F0008C170C140000000083128D0A03198F0A5A :060300000C0803130800C5 :02400E004E3F23 :00000001FF Cheers! Michael

sorry. haven't scrolled up and thought you were talking of eagle ;D no, obviously no mac version for the eagle3d... :-\

Hi TK :) its gpasm-0.13.3 beta I just checked on sourceforge; the latest is 0.13.4 should I upgrade? cheers, Michael Edit: Michaël has been so kind to compile the project; I discovered some differences to my compiled version; so I know now it has someting to do with my version of GPASM :-\ ...keep you updated!

Hey, Michaël! that's great!! :) ...although, I got the feeling that it may be some misconfiguration in my GPASM installation :-\ I uploaded the modified files here: http://www.audiocommander.de/downloads/midibox/mbhp_iic_speakjet_v1_1.tgz It's just that one line 62 in uart.asm: 62: ;; #define UART_TX_BUFFER_SIZE 0x60 63: #define UART_TX_BUFFER_SIZE 0x20 Thanx alot – Cheers, Michael

bis jetzt klingt das alles normal. Die Luminanz ist nur bei einigen LCDs regelbar. Grüße, Michael

es ist bei fast jeder applikation mit dabei (auf der ucapps-downloadseite); meist im ordner "tools" ;)

nachdem ich die SID-syx nicht habe, hier eine Erklärung der Syntax: Eine Beschreibung wie Du hex2syx.pl verwenden kannst, findest du hier: http://www.ucapps.de/howto_tools_hex2syx.html Ich kann dir hier nur eine *nix-Methode (Linux, Unix, Mac OSX) via bash (terminal) beschreiben, aber auf DOS wird es wohl ähnlich sein; im Zweifelsfall kannst du danach googeln; das Prinzip ist für alle möglichen kleinen (Perl-)Programme gleich: Perl Scripts ruft man so auf: [tt]./script.pl[/tt] in deinem Fall wechselst du also in das Verzeichnis, wo das Script liegt, z.B. so: [tt]cd ~/meinVerzeichnis/tools/[/tt] dann das Script so aufrufen: [tt]./hex2syx.pl[/tt] Wenn du das so machst, solltest du eine Fehlermeldung sehen, dass das Script nicht weiß, was es konvertieren soll: also musst du nur noch die zu konvertierende Datei danach angeben; nehmen wir an, dass alles im gleichen Verzeichnis liegt: [tt]./hex2syx.pl mios_v1_9c_pic18f452.hex[/tt] Für "normale" MIOS-Anwendungen würde das schon genügen, wenn du aber MIOS konvertierst, musst du dem script mitteilen, dass es sich hier um das "Betriebssystem" handelt, also bestimmte Adressbereiche überschrieben werden können (müssen). Du kannst es gerne ausprobieren und dir die Fehlermeldung anschauen ;) Also heißt die Zeile: [tt]./hex2syx.pl mios_v1_9c_pic18f452.hex -os_upload[/tt] das mit der device_id kannst du für die SID-syx Datei auf der o.g. Seite nachsehen. Hoffe, das hilft ;) Viele Grüße, Michael ps: wenn du das am Mac im Terminal machst, kannst du der Einfachheit halber Ordner oder Dateien auf das Terminalfenster ziehen; damit setzt du den Pfad ein. Das spart ein wenig nervige Tipparbeit :)

Thanks th0mas for that link... I'm infected by speech synthesis and ordered some speech-Chips. They have just 10$ shipping from US to Germany, that's good :) btw: I resumed working on the SpeakJet Application... I'm currently sorting around some vowels and consonants based on their position in the mouth (did you know that "VV" is labiodental wheras "TH" is interdental ;D ?)... ...and I wanted to adapt the new buffer size for the PIC16F firmware... But apparently I am too dumb to generate a new hex-file. I'm generating a new makefile based on (unchanged settings) in the makefile.spec, a new hex-file is generated, that is apparently nearly the same as the original one, but as soon as I try to load this hex-file in PBrenner, the app crashes :( With PBrenner NG (newer program version), I get an error "Fehler bei Bereichsprüfung" (Error in Range Check)... Do I have to adapt the linker-script? hmm... any hint is greatly appreciated! Cheers! Michael