audiocommander

Yes. This has been asked before ;) : http://www.midibox.org/forum/index.php?topic=6528.msg40953#msg40953 Don't miss the pdf, it shows how to wire the button. See "mios_pin_list.txt" (also to be found on the download page) to find out what pins of the core you can use. Regards, Michael.

I only buy items on eBay if I'm sure I can deal with loosing that money and not seeing the delivery. It's a risk one has to take, so I'm only buying for a real good price so that it's worth the risk. You also have to keep in mind that maybe you get a bad rating, too. ("get 1 bad rating when buying 1 non-delivered product for free!" ;D ) But, hey, this unbelieveable story seems to be worth the money; this sounds like a movie plot ;D Regards, Michael

Maybe this is SDCC related? I noticed that it's not possible to define a bitfield with more than 8 bits. But this doesn't seem to be a big handicap, right? ;) Michael

AFAIK it's not that easy. As DMX is based on a serial RS-485 protocol, I doubt you can directly connect it to J4 (which is - if I remember right) the IIC-Jumper. If you're into the DMX Protocol you might check out the IIC-MIDI-Bridge pages on uCApps.de which actually use a PIC16F. I assume you'll have to write a firmware for the PIC16F to do IIC/DMX-Conversion. DMX-circuit -> PIC16F for Protocol Conversion -> communication via IIC to the Core Module (PIC 18F). I would be lucky to build a DMX2MIDI vv controller as well, but I always found some (price- or knowledge related) problems that kept me away from it so far :-\ Keep us updated if you're going to build one! ;) Regards, Michael Edit: You can program the Core in C; for the PIC16F you might use ASM, but I'm not sure of that, maybe C is also an option for the PIC16F...

Allright, I found it by myself: if anyone has the same problem, just change cache=cache from the addressbar to cache=nocache, then the image will be updated. michael ;)

Hi, as I'm not sure who's the responsible admin for the wiki, I'm asking it loud: I made an error on a graphic and updated the original image, but the wiki-pic-cache still loads the errorneous image? wrong: :P http://www.midibox.org/dokuwiki/lib/exe/fetch.php?cache=cache&media=http%3A%2F%2Fwww.audiocommander.de%2Fpics%2Fsonst%2FMIOS_Overview.gif right: ;) http://www.audiocommander.de/pics/sonst/MIOS_Overview.gif thanks Michael

Hi, that makes it a lot clearer :) thank you! Because I cannot group my int arrays to bitfields (SDCC just allows 8 bit / field), this sounds like it's best to create structures of 64 bytes, so that I can simply send the whole structure to write a page, right? Thanks again for clearifying this, Michael ----- @Stryd_one: yeah, I updated the code each time I did improve something, so although I tried to comment out everything related to my app, some lines might have slipped through ;) But this should be just the "runloop", that can be heavily customized to your needs, it's not really encapsuled... drop me a line if you have problems or questions!

I think I'm speaking for everyone here if I say: do so! We definitely need the help of anyone willing to add information to the wiki :) your effords will be appreciated! Michael

Hi, as I am not really capable of understanding the ASM-code from the provided application examples that use bankstick patches, maybe someone might check if my concept of storing patches on a bankstick seems correct? I noticed that my codesize increased rapidly (>50%) due to my implementation of read/save handlers to store patches on a bankstick. This is not critical but it makes me wonder if there's a more efficient method for this. Here's what I'm doing: Every patch consists of AIN_NUM * 16 bytes. I have a const unsigned int array bankstick_patch_address[MAX_PATCHES] that points to the address of the bankstick. Then I have two accessor functions, that collect or set the current data and two functions that read/store the whole patch: (the code is cutted to the relevant) #define MAX_PATCHES 16 const unsigned int bankstick_patch_address[MAX_PATCHES] = { 0x000, 0x040, 0x080, 0x0C0, 0x100, 0x140, 0x180, 0x1C0, 0x200, 0x240, 0x280, 0x2C0, 0x300, 0x340, 0x380, 0x3C0 }; void ZS_SENSORIZER_SensorSetting_Write(unsigned int address, unsigned char pin) { // called by ZS_SENSORIZER_SensorSettings_Write(address) MIOS_BANKSTICK_Write(address, ZSSENSORIZER_VERSION); MIOS_BANKSTICK_Write(address + 1, (sensor[pin].enabled) | (sensor[pin].pedal << 1) | (sensor[pin].pedalPanic << 2) | (sensor[pin].invert << 3) | (sensor[pin].gate << 4) | (sensor[pin].read << 5) | (sensor[pin].expand << 6) | (sensor[pin].scale << 7)); MIOS_BANKSTICK_Write(address + 2, CH[pin]); MIOS_BANKSTICK_Write(address + 3, CC[pin]); } void ZS_SENSORIZER_SensorSetting_Read(unsigned int address, unsigned char pin) { // called by ZS_SENSORIZER_SensorSettings_Read(address) // read and set sensor config from Bankstick if(MIOS_BANKSTICK_Read(address) != ZSSENSORIZER_VERSION) { return; } // read and set sensor pin from buffer // set sensor settings from buffer sensor[pin].enabled = 0x0 | (MIOS_BANKSTICK_Read(address + 1)); sensor[pin].pedal = 0x0 | (MIOS_BANKSTICK_Read(address + 1) >> 1); sensor[pin].pedalPanic = 0x0 | (MIOS_BANKSTICK_Read(address + 1) >> 2); sensor[pin].invert = 0x0 | (MIOS_BANKSTICK_Read(address + 1) >> 3); sensor[pin].gate = 0x0 | (MIOS_BANKSTICK_Read(address + 1) >> 4); sensor[pin].read = 0x0 | (MIOS_BANKSTICK_Read(address + 1) >> 5); sensor[pin].expand = 0x0 | (MIOS_BANKSTICK_Read(address + 1) >> 6); sensor[pin].scale = 0x0 | (MIOS_BANKSTICK_Read(address + 1) >> 7); CH[pin] = (MIOS_BANKSTICK_Read(address + 2)); CC[pin] = (MIOS_BANKSTICK_Read(address + 3)); } void ZS_SENSORIZER_SensorSettings_Write(unsigned int address) { // write all sensor configs to Bankstick // 1 sensor setup needs 16 bytes (c << 4 => c * 16) unsigned char c; for(c=0; c<SENSOR_NUM; c++) { ZS_SENSORIZER_SensorSetting_Write((address + (c << 4)), c); } } void ZS_SENSORIZER_SensorSettings_Read(unsigned int address) { // read and install all sensor configs from Bankstick // 1 sensor setup needs 16 bytes (c << 4 => c * 16) unsigned char c; for(c=0; c<SENSOR_NUM; c++) { ZS_SENSORIZER_SensorSetting_Read((address + (c << 4)), c); } } for example, the patch is then loaded by calling this: // load patch #5 ZS_SENSORIZER_SensorSettings_Read(bankstick_patch_address[5]); Now I wonder: - should I store the address lookup table on the bankstick to save memory? - should I rather find a bitshifting formula that increments the address like this: PATCH * 0x40 ? (I already hammered my brain out, I just can't figure it out :-[ ) - is this concept okay or is there a better method for this? Cheers, Michael

Heya all smiters and applauders, I've been away the last few days. Have I missed something? Where's the karma gone? Ahh, what a relief... feels quite good without... no worries 'bout bad karma anymore ;) Any rumours? :) Or shall I better shut my mouth to catch no flies anymore ;D

no, it's not only stryd_one anymore. someone is giving smites to anyone posting in this thread.

hey stryd, what's going on now, who smited you again? That's not nice >:( Isn't there a function, board add-on or plugin, where we can get to know on what posting the "-" has been applied? It seems to me that karma – as good as it is to push someone for contributing more to the community – it might also cause the opposite. Michael. @David: once you have composed 50 postings, you can applaud/smite nice avatar btw ;D Edit: huhu, David, where is your message gone? Or am I seeing postings that are not there... ??? tss...

I wondered too, if I missed an interesting dispute ;D I know how it feels, because I've been also given bad karma without knowing a reason some time ago... Lucky me, I got rid of it due to thy merciful board moderator :D Whoops, seems I also accidentally hit applause ;D

thanks Moebius ;)

I have a question about the MAX232 IC, because I wonder if I ordered the right ones: a MAX232 EPE and a MAX232 EEPE. Now I question myself if I should have ordered a MAX232 A EPE instead... ::) This is quite confusing, because Reichelt has 7 MAX232 DIL-16 ICs, and after 3 days searching, I still can't figure out the differences, except their temperature range: 0° to 70°C and -40° to 85°C... huu, this confuses me... ??? anyone knows if I can take these? Thanks!!! btw: don't we have -50°C in the luggage-area of a plane?

Just wanted to throw in a reminder that we have this entry in the Wiki: http://www.midibox.org/dokuwiki/doku.php?id=soundcards_with_ymf262_and_or_yac512_chips Maybe you want to add your link and experiences also in there ;) Regards, Michael

versuchst du vielleicht MIOS v1.9 auf einen älteren bootloader zu laden? Oder umgekehrt? probier es mal mit der MIOS 1.9 version inkl. bootloader-update... oder einfacher (zum testen) erst mal mit MIOS v1.8 (und ich hoffe, dass ich die meldung mit dem address range richtig interpretiere, denn so wie ich das sehe, versucht da irgendwass einen adressbereich zu überschreiben, der reserviert ist)

nein, es ist kein bankstick nötig. hast du den pic selbst gebrannt? normalerweise sollte da "Ready." stehen, wenn der bootloader bereit ist

Not exactly this, but something like this is the SpeakJet, a single chip for ~25$ that you can control with a IIC-module and a Core-module. TK has just released the plans and a first firmware! The SpeakJet can talk phonemes, words and phrases, you can control pitch and speed and it has some additional sound-fx and DTMF-tones. Documentation is minimal at this moment, but there are some of us planning to build this, so help and hints should be available. You might want to check out this thread: http://www.midibox.org/forum/index.php?topic=2870.0 ;)

You rock, TK!!! I hope I will find time to start building my speakjet machine in about one or two weeks and will post my code then (and maybe hitting that button on top of this page again ;D ) Thank you! Michael

Hi Bill, as mentioned, I'm not the guy to do ASM, so please don't see my solution as the quickest, best or fastest; but if you can code C it may be the easiest - if that what you get from the keyboard are really just encoded ON/OFF states (I don't know about PS/2 or whatever signals may come out of a keyboard), I would proceed like this: - add a DIN to your Core - connect the 8 wires from the Keyboard to 8 DIN pins - setup a global variable c64matrix[8]; to save space you could create a bitfield. - now you just have to use the DIN_NotifyToggle() Function, just place your appropriate handler there. It will notify you whenever a state is switching. Use the global c64matrix to prevent having to check all the other seven pins on notify toggle: ///////////////////////////////////////////////////////////////////////////// // This function is called by MIOS when an button has been toggled // pin_value is 1 when button released, and 0 when button pressed ///////////////////////////////////////////////////////////////////////////// void DIN_NotifyToggle(unsigned char pin, unsigned char pin_value) __wparam { // update the matrix c64matrix[pin] = value; // check what to do switch(c64matrix) { case 0x00: // e.g. key '0' pressed do_that(); break; case 0x01: // e.g. key 'a' pressed do_this(); break; default: do_nothing(); break; } } I think, this might be easy, if the keyboard is really just en-/decoding states; ;) Regards, Michael

Wow. :o This sounds promising ;D btw. if anyone is interested in historic talking machines, I wrote a nice article/abstract with a lot of links on baron kempelen some while ago: http://www.audiocommander.de/blog/?p=27 (german) :D

oh! no! :'( I was so overwhelmed of the headline... I couldn't read any further... ;D However, I subscribed to the speakjet yahoo group and a first glimpse showed me that this topic is obviously widespread. Your solution with two Cores (and different baud rates) seems to be the recommended method. I'm going to read on and post if I find sth interesting... :-\ Edit: indeed there are some really interesting files available, such as connection diagrams to a MAX232 and PIC assembler symbols & tables and some more PIC16/18F sources :)

Yipee ;D My SpeakJet arrived today!! Wonderful! It seems to be exactly what I was looking for. The Phonetic Usage Table from the Datasheet looks delicious :D Now I wonder if I can use a DOUT or some free Core-Pins as TTL-Logic Control. The datasheet says the SpeakJet can be controlled by RS232 and/or by its 8 Event Input Lines. Seems a lot more comfortable than using the (not fully compatible) RCX Serial Input? With 8 setable pins and an appropriate application, the integration of the chip should to be a cinch :)

http://www.midibox.org/dokuwiki/doku.php?id=introduction_to_ucapps.de Your're welcome ;) btw: there have been made some ableton live controllers concepts. just search a bit here in the forum!